✨ [RUM-10146] implement trackEarlyRequests

[BenoitZugmeyer]

Motivation

This PR introduces a new initialization parameter to opt-in tracking "early requests", i.e. fetch and XHR resources that happen before the SDK is initialized.

This will be the default behavior in the next major version, but until then this feature is opt-in, because it could introduce a (very small) breaking change: when using beforeSend, properties associated to the request can now be undefined. Ex:

DD_RUM.init({
  ...,
  beforeSend(event, eventContext) {
    if (event.type === 'resource' && event.resource.type === 'xhr') {
      eventContext.xhr.response // This might now break because `eventContext.xhr` is not necessarily defined
    }
  }
})

Changes

Replace the "experimental flag" track_early_requests with a public init parameter trackEarlyRequests.

Test instructions

In the sandbox:

      fetch('/zog')
      DD_RUM.init({
        clientToken: 'xxx',
        applicationId: 'xxx',
        trackEarlyRequests: true,
      })

The request /zog should be collected as a RUM resource.

Checklist

• Tested locally
• Tested on staging
• Added unit tests for this change.
• Added e2e/integration tests for this change.

[datadog-datadog-prod-us1]

✅ Tests

🎉 All green!

❄️ No new flaky tests detected
🧪 All tests passed

🎯 Code Coverage
• Patch Coverage: 100.00%
• Total Coverage: 92.35% (-0.00%)

View detailed report

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: b4ff364 | Docs | Was this helpful? Give us feedback!}

[cit-pr-commenter]

Bundles Sizes Evolution

📦 Bundle Name	Base Size	Local Size	𝚫	𝚫%	Status
Rum	160.90 KiB	160.92 KiB	11 B	0.01%	✅
Rum Recorder	19.53 KiB	19.53 KiB	0 B	0.00%	✅
Rum Profiler	5.18 KiB	5.18 KiB	0 B	0.00%	✅
Logs	55.82 KiB	55.77 KiB	-54 B	-0.09%	✅
Flagging	N/A	931 B	931 B	N/A%	✅
Rum Slim	118.55 KiB	118.57 KiB	19 B	0.02%	✅
Worker	23.60 KiB	23.60 KiB	0 B	0.00%	✅

🚀 CPU Performance

Action Name	Base Average Cpu Time (ms)	Local Average Cpu Time (ms)	𝚫
addglobalcontext	0.006	0.005	-0.000
addaction	0.020	0.015	-0.005
addtiming	0.004	0.007	0.003
adderror	0.020	0.016	-0.005
startstopsessionreplayrecording	0.001	0.002	0.001
startview	0.005	0.008	0.004
logmessage	0.018	0.032	0.015

🧠 Memory Performance

Action Name	Base Consumption Memory (bytes)	Local Consumption Memory (bytes)	𝚫 (bytes)
addglobalcontext	24.37 KiB	25.11 KiB	754 B
addaction	43.79 KiB	46.60 KiB	2.81 KiB
addtiming	24.98 KiB	25.07 KiB	90 B
adderror	49.01 KiB	49.41 KiB	405 B
startstopsessionreplayrecording	24.18 KiB	24.24 KiB	68 B
startview	422.20 KiB	430.87 KiB	8.66 KiB
logmessage	41.58 KiB	41.93 KiB	356 B

🔗 RealWorld

[BenoitZugmeyer]

/to-staging

[dd-devflow-routing-codex]

View all feedbacks in Devflow UI.

2025-09-17 10:14:55 UTC ℹ️ Start processing command /to-staging

---

2025-09-17 10:15:02 UTC ℹ️ Branch Integration: starting soon, merge expected in approximately 11m (p90)

Commit b4ff364e61 will soon be integrated into staging-38.

---

2025-09-17 10:15:15 UTC 🚨 Branch Integration: this merge request has conflicts which couldn't be solved automatically

We couldn't automatically merge the commit b4ff364e61 into staging-38!

To solve the conflicts directly in Github, click here to create a fix pull request.

Alternatively, you can also click here reset the integration branch or use the following Slack command: /devflow reset-branch -r browser-sdk -b staging-38

[dd-devflow]

🚂 Branch Integration: starting soon, merge expected in approximately 11m (p90)

Commit b4ff364e61 will soon be integrated into staging-38.

[dd-devflow]

🚂 Branch Integration

Commit b4ff364e61 has been merged into staging-38 in merge commit 9815549155.

Check out the triggered pipeline on Gitlab 🦊

If you need to revert this integration, you can use the following command: /code revert-integration -b staging-38