Skip to content

fix(tracing): establish tracing capture context early enough - #3057

Draft
solnic wants to merge 5 commits into
masterfrom
3015-railsrackloggers-started-log-line-and-anything-else-logged-before-sentryrailscaptureexceptions-gets-an-unrelated-trace_idspan_id
Draft

fix(tracing): establish tracing capture context early enough#3057
solnic wants to merge 5 commits into
masterfrom
3015-railsrackloggers-started-log-line-and-anything-else-logged-before-sentryrailscaptureexceptions-gets-an-unrelated-trace_idspan_id

Conversation

@solnic

@solnic solnic commented Aug 19, 2026

Copy link
Copy Markdown
Collaborator

This is based on #3016


This adds a new Sentry::Rails::CaptureContext middleware establishes the propagation context once, early. CaptureExceptions reuses it instead of generating its own, and a transaction with no incoming trace continues the established one rather than fabricating a new trace_id.

It sits insert_after ActionDispatch::Executor - above Rails::Rack::Logger so the fix covers the logging, below the file-serving middlewares so static requests never touch Sentry.


Fixes #3015

@solnic solnic changed the title 3015 railsrackloggers started log line and anything else logged before sentryrailscaptureexceptions gets an unrelated trace idspan fix(tracing): establish tracing capture context early enough Aug 19, 2026
Comment thread spec/apps/rails-mini/app.rb Dismissed
runephilosof and others added 4 commits September 2, 2026 14:14
Rails::Rack::Logger's "Started ..." line (and anything logged before
CaptureExceptions runs) got an unrelated trace_id, since
CaptureExceptions runs after ActionDispatch::ShowExceptions.

Add Sentry::Rails::CaptureContext, a minimal middleware unshifted to
the front of the stack that establishes the propagation context early.
CaptureExceptions now consumes and reuses it instead of regenerating
a new trace_id/span_id.

Co-Authored-By: GitHub Copilot <noreply@example.com>
This fixes the issue while ensuring we're not adding
Sentry overhead to static file-serving routes, which
is why the middleware was moved historically.
The established flag lived in the request-scoped env but certified a
thread-local hub, so any middleware doing `@app.call` on another thread
lost the incoming trace. The env now carries the context itself, trusted
only while it is still the current scope's.
@solnic
solnic force-pushed the 3015-railsrackloggers-started-log-line-and-anything-else-logged-before-sentryrailscaptureexceptions-gets-an-unrelated-trace_idspan_id branch from 029569e to 01910dc Compare September 2, 2026 14:25
The example stubs Sentry.initialized? to false, and RSpec tears mocks down
after the suite's after hooks run. The sentry-rails hook only clears captured
events and detaches the structured logging subscribers when Sentry reports
itself initialized, so the stub made it skip both. The subscribers stayed
attached and later examples inherited log events they never emitted, failing
whenever the order put them after this one.

Scoping the stub to the call under test lets the hook see the real state.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Rails::Rack::Logger's "Started ..." log line (and anything else logged before Sentry::Rails::CaptureExceptions) gets an unrelated trace_id/span_id

3 participants