Fix trace_id mismatch for logs emitted before Sentry::Rails::CaptureExceptions runs

[runephilosof-abtion]

Fixes #3015

Problem

Sentry::Rails::CaptureExceptions is deliberately positioned right after ActionDispatch::ShowExceptions (to skip transaction creation for static asset requests). That means anything logged before it runs - most notably Rails' own Rails::Rack::Logger "Started ..." line - gets a trace_id/span_id unrelated to the rest of the request, because no trace context has been established yet.

There's also a second, compounding issue: even once CaptureExceptions does run, if the request isn't continuing an incoming distributed trace, Hub#start_transaction's fallback (Transaction.new(**options)) generates its own independent trace_id, ignoring whatever was already on the scope's propagation context.

Fix

• New Sentry::Rails::CaptureContext middleware, unshifted to the very front of the Rails middleware stack. It only establishes the propagation context (from incoming sentry-trace/baggage headers, if present) as early as possible - it doesn't start a transaction or capture exceptions, so CaptureExceptions's existing position/behavior is untouched.
• Sentry::PropagationContext::ESTABLISHED_ENV_KEY - a new env flag signaling that trace context was already established for this exact request.
• Sentry::Rack::CaptureExceptions reads and deletes this flag from env atomically, as the very first thing it does (before anything else that could raise), so it can never leak into later, unrelated reuses of the same env (e.g. Action Cable holding onto the handshake env for a connection's lifetime). It skips re-cloning the hub when the flag was present, and passes the result explicitly as an established: argument to Hub#continue_trace and Hub#start_transaction.
• Hub#continue_trace skips regenerating the propagation context when established: true, instead of clobbering what CaptureContext set up.
• Hub#start_transaction, when not continuing a distributed trace and established: true, builds the new transaction with the already-established trace_id/sample_rand instead of generating an unrelated one.

The start_transaction change is intentionally scoped to only apply when the established: flag is passed (rather than always reusing whatever's on the scope), to avoid incorrectly linking together unrelated transactions that happen to share a thread (e.g. separate background jobs) - each of those still gets its own independent trace_id as before. This was verified against a regression in sentry-rails' ActiveJob distributed-tracing specs during development.

Testing

• Added sentry-rails/spec/sentry/rails/capture_context_spec.rb, including an integration-style test that reproduces the original bug (probe middleware inserted before/after CaptureExceptions) both with and without tracing enabled.
• Added unit coverage in sentry-ruby's hub/capture_exceptions specs for the new established-context guard behavior.
• Updated sentry-rails' existing middleware-ordering spec to assert CaptureContext is the first middleware.
• Ran the full sentry-ruby and sentry-rails suites locally; no regressions (Redis-dependent specs fail identically with/without this change due to no local Redis server, pre-existing/environment-only).

[runephilosof-abtion]

Should I cut down on the inline code comments?

[solnic]

Should I cut down on the inline code comments?

@runephilosof yes please 🙏🏻 😄 public APIs should only get proper YARD coverage, any other inline comment is not needed except situations where some bit is really tricky to understand by just looking at the code.

[runephilosof-abtion]

I have changed how the already established info is passed around, to make it less confusing and force pushed.

[cursor]

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.}

Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit f855b07. Configure here.}