fix(v10/core): Don't instrument the SDK's own envelope requests - #24276
Merged
Merged
Conversation
logaretm
marked this pull request as ready for review
September 10, 2026 03:09
logaretm
requested review from
JPeer264,
andreiborza and
isaacs
and removed request for
a team
September 10, 2026 03:09
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 06819f1. Configure here.
Contributor
size-limit report 📦
|
Contributor
|
👋 @isaacs, @JPeer264, @andreiborza — Please review this PR when you get a chance! |
JPeer264
approved these changes
Sep 15, 2026
JPeer264
left a comment
Member
There was a problem hiding this comment.
LGTM. Two questions though:
- Don't we have this issue in v11 ? Since this is not a classic backport PR
- Do you know which PR introduced this behavior?
Member
Author
|
@JPeer264 It looks accidental to me, both that it happens in v10 and that it doesn't in v11
|
Member
|
Cool thanks. |
The outgoing-http subscription skipped Sentry's own transport requests by checking the scope for an active `suppressTracing()`. That check is unreadable when the SDK does not own the OpenTelemetry setup (`skipOpenTelemetrySetup: true`, or any other setup that leaves the OTel API without a registered context manager): the suppression is written to a context that nothing propagates. Each envelope send then started an outgoing-request span, and with tracing off that span was dropped with a `no_parent_span` outcome. Since 10.72 a healthy process also sends its session on `beforeExit`, which seeded the first outcome, and from there the client report flush on `beforeExit` fed itself: flush -> instrumented request -> new outcome -> `beforeExit` again. The process never exited and hammered the DSN with client reports. Requests to the ingest endpoint are now recognized by URL, which does not depend on context propagation. Fixes #24262
The watchdog marker meant a scenario that died on startup looked the same as a clean exit, so the test passed with and without the fix when the worktree's node_modules were broken. Polling for the child's exit with `ensureNoErrorOutput` separates the two, and it keeps the passing run under a second instead of always sleeping 5s.
logaretm
force-pushed
the
awad/fix-client-report-exit-loop
branch
from
September 15, 2026 14:37
6c0b949 to
85ce063
Compare
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
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.

Stops the outgoing-http instrumentation from instrumenting Sentry's own envelope sends.
It recognized them only via
suppressTracing(), which is unreadable when the SDK doesn't own the OTel setup, since no context manager propagates it. Each send then started a span that got dropped asno_parent_span, and since 10.72 the session sent onbeforeExitseeds the first outcome, so the client report flush feeds itself and the process never exits. Matching the ingest URL instead doesn't depend on context propagation.closes #24262