Repository navigation
Conversation
|
bugbot run |
size-limit report 📦Compared: f9003cd (PR test merge using develop at 8042719) Against: 8042719 (develop) · base run #63102 ✅ Baseline matches: this diff contains only this PR's changes.
|
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit e4c2c57. Configure here.
|
|
||
| if (flushNow) { | ||
| flushPendingClientAggregates(); | ||
| } |
There was a problem hiding this comment.
Flush-now skips existing aggregates
Medium Severity
When a request session settles after client.flush(), flushNow only sends if this call created the aggregate. Another request that records during that wait can already have opened a bucket, so this session is added and not sent. The in-flight flush then drains the transport without it, and a shutdown flush can drop the session.
Reviewed by Cursor Bugbot for commit e4c2c57. Configure here.
There was a problem hiding this comment.
I think one way we could solve this is by adding something like an afterFlushProcessing client hook that the client emits in its flush method after determining clientFinished. This should allow us to get rid of the flushNow flag that only worked locally for this request
Optional E2E testsSome optional checks were not successful. They do not block the merge. 2 failing, 62 successful. See the run.
Successful checks
|
Lms24
left a comment
There was a problem hiding this comment.
Thanks for fixing this, I admittedly forgot about the server side part when we made the change in browser.
Took me a bit to understand the pendingRequests logic but I think it's fine and shouldn't hurt us or leak memory (that is assuming the isolationScope cleans up at which point the references to the pending errors should be gc'd).
I think we still should address the bugbot comment but otherwise, looks great!
The scenario sets `sessionFlushingDelayMS` on `httpIntegration`, which has no effect with `@sentry/bun`, so the session aggregate arrives after the test timeout.
…n-filtered-errors


Errors that
ignoreErrors,beforeSendor an event processor drops no longer mark the request session as errored or crashed. Errors thatsampleRatedrops still count. This is the same rule that already applies to client sessions since #22671.Before,
ServerRuntimeClientset the request session status incaptureException/captureEvent, before the event pipeline ran. Now the status is set at the same point in the pipeline as the client session update.Event processing can finish after the response ends (e.g. async ContextLines reads). Because of this, the request session now waits for its pending error events before it is recorded. If
client.flush()runs during that wait, the session is sent immediately. This is necessary because the flush sends the aggregate before it waits for event processing.Fixes #25605