Conversation
|
✨ Fix all issues with BitsAI or with Cursor
|
Bundles Sizes Evolution
🚀 CPU Performance
🧠 Memory Performance
|
the old `matchRequestResourceEntry` approach (polling `performance.getEntriesByName` on request completion) is superseded by the registry-based path that was behind the `trackEarlyRequests` flag. remove the flag and always use the registry, which also drops the `pageStateHistory` dependency and the frozen-state duration workaround.
The WAIT action was introduced so that fetch request duration could be derived from waiting for the response body to be fully consumed. Now that resource timing always comes from PerformanceResourceTiming (early request collection is the only path), waiting for the body before reporting a resource is no longer necessary. This also simplifies readBytesFromStream, which is now always called to collect bytes (never just to wait).
Early request collection is now always enabled, making this option a no-op. Remove it from the public API, internal configuration, and telemetry.
now that fetch and xhr resources always have a performance entry and may or may not have request information, separate context types per request type make less sense. replace RumFetchResourceEventDomainContext, RumXhrResourceEventDomainContext and RumOtherResourceEventDomainContext with a single RumResourceEventDomainContext.
8c3d1f0 to
c99a9b7
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c99a9b768b
ℹ️ 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".
| const performanceResourceSubscription = createPerformanceObservable(configuration, { | ||
| type: RumPerformanceEntryType.RESOURCE, | ||
| buffered: true, | ||
| }).subscribe((entries) => { |
There was a problem hiding this comment.
Restore request fallback when resource timings are unavailable
This change makes resource collection depend exclusively on PerformanceObserver entries, so when a fetch/xhr timing is missing or filtered out (for example the negative-duration entries explicitly dropped in packages/rum-core/src/browser/performanceObservable.ts:306-310), no resource event is emitted even though REQUEST_COMPLETED was observed. Prior to this commit, the request-based path still produced a resource in that scenario, so this regresses resource/tracing/GraphQL data completeness in affected browsers and edge cases.
Useful? React with 👍 / 👎.
- mention reviewing all PR commits, not just the latest diff - document `agent-browser tab 0` + `agent-browser eval` for inspecting window state
Motivation
Resources initiated early in the page lifecycle (before the SDK is fully initialized) were
previously missed unless
trackEarlyRequestswas explicitly enabled. This change makes thatbehavior the default, ensuring all requests are captured regardless of when they start.
Changes
matchRequestResourceEntrypath (pollingperformance.getEntriesByName)— the registry-based approach is now the only path
trackEarlyRequestsoption (now always enabled, option is a breaking removal)ResponseBodyAction.WAIT— no longer needed since timing always comes fromPerformanceResourceTimingRumFetchResourceEventDomainContext,RumXhrResourceEventDomainContext, andRumOtherResourceEventDomainContextinto a single
RumResourceEventDomainContextTest instructions
Create
sandbox/test-early-requests.html:Checklist