Repository navigation
feat(node): Stop sending the process session once request sessions are tracked - #24915
Merged
Merged
Conversation
…e tracked A Node server reported release health twice: once through request session aggregates, and once through the process session started by `processSessionIntegration`. Request isolation scopes inherited the process session, so the first error in any request also marked the process session as errored. No other server SDK sends a process session alongside request aggregates, and the sessions spec describes servers as request mode only. `recordRequestSession` now removes the inherited session from the request scope and emits a `startRequestSession` client hook. On the first one, `processSessionIntegration` discards the process session, closing it as `exited` if an update was already sent. Processes that never serve tracked requests (scripts, workers, or servers with `sessions: false`) keep the process session as before. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…gates Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Lms24
approved these changes
Oct 1, 2026
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
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 3df3e63. Configure here.
Contributor
size-limit report 📦
|
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… requests Event processing is async (e.g. ContextLines reads files), so on slower machines the first request could arrive and drop the process session before the startup error had updated it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Like `exited-session-aggregate`, it relies on `sessionFlushingDelayMS` passed to `httpIntegration`, which `bunHttpServerIntegration` ignores, so the aggregate is not flushed before the test times out. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
mydea
marked this pull request as ready for review
October 1, 2026 10:44
mydea
requested review from
JPeer264 and
isaacs
and removed request for
a team
October 1, 2026 10:44
JPeer264
approved these changes
Oct 1, 2026
47 tasks done
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A Node server currently reports release health twice: through request session aggregates, and through the process session started by
processSessionIntegration. Request isolation scopes inherit the process session, so the first error in any request also marks the process session as errored, which double counts it. No other server SDK sends a process session alongside request aggregates (Python and Ruby send aggregates only, Rust makes you pick one mode), and the sessions spec describes servers as request mode only.The process session is still useful for processes that don't serve requests (scripts, CLIs, workers), so instead of removing it we switch automatically: on the first tracked request session, the process session is dropped. The process session sends nothing until an error or
beforeExit, so in the common case nothing was ever sent for it. If an update was already sent (an error before the first request), it is closed asexitedso it doesn't stay open forever. Servers withhttpServerIntegration({ sessions: false })never record request sessions and keep the process session as before.Request errors also no longer touch the process session inherited by the request scope, since the aggregate already counts them.
The process session is now started in
setuprather thansetupOnce, so the request-session hook can be tied to the client and the scope that holds the session. As a side effect, callingSentry.init()again in the same process ends the current session and starts a new one, instead of keeping the first.This changes release health numbers for Node servers: they lose the one errored/crashed process-session update they send today.
🤖 Generated with Claude Code