Skip to content

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

Draft
solnic wants to merge 4 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 4 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

runephilosof and others added 3 commits August 19, 2026 13:28
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 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 on lines +263 to +279
class TraceContextController < ActionController::Base
before_action :set_cors_headers

def show
Sentry.logger.info("controller log", source: "controller")

render json: { trace: Sentry.get_current_scope.get_trace_context }
end

private

def set_cors_headers
response.headers["Access-Control-Allow-Origin"] = "*"
response.headers["Access-Control-Allow-Methods"] = "GET, POST, PUT, DELETE, OPTIONS"
response.headers["Access-Control-Allow-Headers"] = "Content-Type, Authorization, sentry-trace, baggage"
end
end
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