we do not have

ZO_CORS_ALLOWED_ORIGINS

set on our O2 instance

Oh wait this is weird, the data does appear to be getting to the O2 server, I can see it in

_rumdata

but when I go to view the sessions i get this

This is also all appearing under our "dev" organization, whereas the functional RUM info from other apps is going to the "default" org

Updated to

v0.92.0

and now the pop-up looks like this

Ah ok, I think since the call to otel is having the CORS issue the session recording isnt actually starting which explains why all of the entries in the

_rumdata

stream have

session_sampled_for_replay

set to false. Whats really odd is that the POST to O2 that correlates with the

startSessionReplayRecording

call (after a customer inputs their phone #) is the one that fails with the CORS issue but the call that correlates with the

stopSessionReplayRecording

call (when the wizard resets) succeeds. Heres a recording

Sorry to spam, but I found that if I add

ZO_CORS_ALLOWED_ORIGINS

with the specific origin I'm using I dont get the CORS issue. Id rather not set

ZO_CORS_ALLOWED_ORIGINS

because we want to allow all origins. Also even with that the RUM recordings aren't actually starting 🤔

Oh hey I got it to work, but by using

@openobserve/browser-logs

and

@openobserve/browser-rum

at version

^0.2.11

instead of

^0.4.1

!