feat(browser): XHR spans and page load timing - #1147
Merged
Makisuo merged 4 commits intoSep 29, 2026
Merged
Maple Review Bot / Maple / review
completed
Sep 29, 2026 in 7m 9s
Confidence 3/5 · 1 issue to address
Confidence 3/5 · needs attention
The new document-timing child spans start before any consent grant and are dropped by the consent filter, untested in that configuration.
quality 90/100 · 1 warning · tests partial · risk medium · 2/2 new units observable
Adds XHR auto-instrumentation with a shared HTTP status policy, a replay trace-id link for XHR, and Navigation-Timing child spans under pageload. Safe to merge apart from the page-load breakdown being dropped on consent-gated installs.
XMLHttpRequestInstrumentationshares fetch's ignore/propagate/settle optionsHttpStatusExporterunsets an Error set only by response statuspageloadstarts at clamped navigation start; document timing spans added- Replay capture records the trace id started in XHR
open()
Still open from earlier reviews
- Warning · F2 · Status policy clears Error on 5xx client spans too, not just 4xx ·
packages/browser/src/http-status.ts:15
What was checked
pageloadstart clamp (navigation.ts:92) is followed by the consent test atnavigation.browser.test.ts:728ConsentSpanExporterfilters on each span's own start time (tracing.ts:80)- Replay link reads
__mapleTraceId ?? activeTraceId()(network.ts:72) and its test fails without the open() capture
Observability coverage: 2 of 2 changes observable
| Change | Kind | Observable | Evidence |
|---|---|---|---|
| XHR auto-instrumentation | outbound call | yes | XMLHttpRequestInstrumentation registered on Maple's provider (tracing.ts:260) |
| Document page-load child spans | background work | yes | documentFetch/dns/connect/request/response/domProcessing/loadEvent started under pageload (deferred/document-timing.ts:37,44) |
36fdc83 · Updated on every push. Reply "won't fix" to dismiss a finding, or mention @maple to ask about one.
Loading