🐛 Initial version of RUM view event is missing global context

[dstepp-indeed]

Describe the bug
We recently upgraded our DataDog RUM client from v5 to v6.19.0. We funnel all RUM log events through a proxy that locally captures the data for later internal analytics before sending it on to DataDog. We noticed that there has been a change to the v6 client where an initial version 1 of the view event is sent up without any of the global context attached.

FWIW, after trying different versions, I have found that this bug entered the DD RUM browser sdk client exactly in version 6.6.3. v6.6.2 does not exhibit this bug and 6.6.3 does.

The relevant code to initialize the RUM client is something like this:

for (each of several global context properties) {
  datadogRum.setGlobalContextProperty(key, value);
}
datadogRum.init({ ... config ... });
datadogRum.startView();

For completeness, I will include the initial view event's JSON data, with slight redaction to xxx for a few fields:

{
  "type": "view",
  "_dd": {
    "format_version": 2,
    "drift": 1,
    "configuration": {
      "session_sample_rate": 0,
      "session_replay_sample_rate": 100,
      "profiling_sample_rate": 0,
      "start_session_replay_recording_manually": true
    },
    "sdk_name": "rum",
    "page_states": [
      {
        "state": "active",
        "start": 0
      }
    ],
    "document_version": 1
  },
  "application": {
    "id": "xxx"
  },
  "date": 1761171363445,
  "source": "browser",
  "view": {
    "url": "xxx",
    "referrer": "",
    "id": "1f51f66d-b4aa-4079-94ac-303c893b1320",
    "action": {
      "count": 0
    },
    "frustration": {
      "count": 0
    },
    "cumulative_layout_shift": 0,
    "error": {
      "count": 0
    },
    "is_active": true,
    "loading_type": "initial_load",
    "long_task": {
      "count": 0
    },
    "performance": {
      "cls": {
        "score": 0
      }
    },
    "resource": {
      "count": 0
    },
    "time_spent": 817000000
  },
  "session": {
    "id": "f568556f-a7c9-47a3-b843-8a8731501722",
    "type": "user",
    "sampled_for_replay": true
  },
  "connectivity": {
    "status": "connected",
    "effective_type": "4g"
  },
  "context": {},
  "usr": {
    "anonymous_id": "xxx"
  },
  "service": "xxx",
  "version": "1.0.0-746bed91",
  "privacy": {
    "replay_level": "mask"
  },
  "device": {
    "locale": "en-US",
    "locales": [
      "en-US",
      "en"
    ],
    "time_zone": "America/Los_Angeles"
  },
  "ddtags": "sdk_version:6.19.0,env:local,service:xxx,version:1.0.0-746bed91"
}

The above view event is followed by later versions of the event for the same view ID that -do- include the context, but this initial version does not, which is breaking some of our view logging that depends on that context being there for all versions of a view. We believe this is a bug and that the context should be there in v1 of the view since it was set prior to the client init and the view starting.

I am not certain, but I believe this issue may affect resource events that are fired off early in the RUM client's lifecycle, too.

If we downgrade to v6.6.2 or earlier, the view v1 event has similar shape as above, but the context member is filled with all of the properties we set prior to initialization.

To Reproduce
See above

Expected behavior
The context property of the version 1 view event should contain all global context properties set prior to the start of the view.

[mormubis]

Hi @dstepp, thank you for reaching out. I have reproduced the issue and will share it with the team.

[roymatzainsait]

This issue affects our organization as well. We’re seeing the same behavior described above, and it’s resulting in gaps and inconsistencies in our data analytics.

[victorcamargos]

Also facing this problem in my organization, thousands of events missing the custom context properties.