✅ delay /empty.css response to fix WebKit early-timings flake

[thomas-lebeau]

Motivation

Fix the top 3 flaky E2E tests of the last 7 days: rum resources › retrieve early requests timings (async / npm / bundle), with 28 / 24 / 21 occurrences across many branches.

• Test runs for this test name (Datadog CI Visibility):
  https://app.datadoghq.com/ci/test-runs?query=%40test.flaky%3Atrue%20%40git.repository.id_v2%3Agithub.com%2Fdatadog%2Fbrowser-sdk%20%40test.name%3A%22rum%20resources%20%E2%80%BA%20retrieve%20early%20requests%20timings%22
• All flaky tests in browser-sdk (last 7 days):
  https://app.datadoghq.com/ci/test-runs?query=%40test.flaky%3Atrue%20%40git.repository.id_v2%3Agithub.com%2Fdatadog%2Fbrowser-sdk

Root cause (verified on CI)

WebKit clamps PerformanceResourceTiming timestamps and performance.now() to 1ms resolution (privacy/Spectre mitigation). For the zero-byte /empty.css served over fast Linux CI loopback, the entire request occasionally completes inside a single 1ms tick. When that happens, every timestamp on the entry (startTime, requestStart, responseStart, responseEnd, …) clamps to the same value, and the SDK truthfully emits duration: 0 and download.start: 0. The existing Safari fallback in computeResourceEntryDuration (packages/rum-core/src/domain/resource/resourceUtils.ts:76) only fires when startTime < responseEnd, so it cannot help when they're equal.

Repro evidence

Verified on CI via PR #4630 (instrumentation + --repeat-each=30 --retries=0, webkit-pinned + chromium):

	Without fix	With fix
webkit-pinned	17 / 90 failed (~19%)	0 / 90 failed ✅
chromium	0 / 90 failed	0 / 90 failed ✅

Sample failing entry from the without-fix run:

raw = {
  startTime: 6, fetchStart: 6, …, requestStart: 6,
  responseStart: 6, responseEnd: 6, duration: 0,
  nowSamples: [567, 567, 567, 567]
}
sdk = { duration: 0, download: {start: 0}, first_byte: {start: 0} }

Compare with Chromium (100 μs resolution — actual sub-ms digits):

startTime: 8.7, requestStart: 9.3, responseStart: 9.8, responseEnd: 10.1, duration: 1.4

Approach: server-side delay on /empty.css

Add a 50 ms setTimeout before the response in the mock server. With a 50 ms gap between startTime and responseEnd, WebKit's 1 ms clamping cannot collapse them — responseStart and responseEnd are guaranteed to fall in different ticks, so the SDK reports real non-zero duration and download.start.

Alternatives considered:

• Relax the test to accept duration >= 0: would silently mask a real bug if the SDK started reporting duration: 0 on Chromium/Firefox (raised by automated review on the earlier iteration of this PR).
• Drop entries when timestamps collapse: silent data loss for legit cached resources in production.
• Floor duration to a minimum in the SDK: fabricates data for customer dashboards; doesn't fix download.start: 0 either.

The server delay keeps expectToHaveValidTimings strict on every browser, so any future regression that zeroes a duration would still be caught.

Changes

• test/e2e/lib/framework/serverApps/mock.ts: wrap the /empty.css response in a 50 ms setTimeout. Comment explains the WebKit clamping and links the failure mode.

Test instructions

• Local: yarn test:e2e -g "retrieve early requests timings" --project=webkit-pinned --repeat-each=10 — 10/10 passed.
• CI repro (PR 🔍 [REPRO – DO NOT MERGE] reproduce early-resource-timings flake on CI #4630): 0/90 failures on webkit-pinned and chromium with --repeat-each=30 --retries=0 (compared with 17/90 webkit failures before the fix).

Checklist

• Tested locally
• Tested on staging
• Added unit tests for this change.
• Added e2e/integration tests for this change.
• Updated documentation and/or relevant AGENTS.md file

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 1dedbfc870

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[datadog-prod-us1-4]

🎉 All green!

❄️ No new flaky tests detected
🧪 All tests passed

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 76.96% (+0.00%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 34b1150 | Docs | Datadog PR Page | Give us feedback!}

[cit-pr-commenter-54b7da]

Bundles Sizes Evolution

📦 Bundle Name	Base Size	Local Size	𝚫	𝚫%	Status
Rum	169.51 KiB	169.51 KiB	0 B	0.00%	✅
Rum Profiler	5.97 KiB	5.97 KiB	0 B	0.00%	✅
Rum Recorder	21.23 KiB	21.23 KiB	0 B	0.00%	✅
Logs	54.70 KiB	54.70 KiB	0 B	0.00%	✅
Rum Slim	127.85 KiB	127.85 KiB	0 B	0.00%	✅
Worker	22.99 KiB	22.99 KiB	0 B	0.00%	✅

🚀 CPU Performance

Pending...

🧠 Memory Performance

Pending...

🔗 RealWorld