Log the real status of exception responses and honour log_rescued_responses

[PetrHeinz]

When a controller raises, the gem logs the request row and a fatal error row, but no http_response_sent row. The status the client gets is never recorded, so dashboards and alerts on 5xx stay blind, and a 404 from ActiveRecord::RecordNotFound shows up only as a fatal error. Yesterday's red-team reproduced this on all seven Rails versions it tested: an exception gave no response row at all, and RecordNotFound was logged as fatal.

What changes:

• The Rails integration sets the new Logtail::Integrations::Rack::HTTPEvents.status_for_exception resolver (from the logtail-rack PR Log a response row with status 500 when the app raises logtail-ruby-rack#27), so the response row that rack now logs for an exception gets the status Rails responds with: ActionDispatch::ExceptionWrapper.new(nil, exception).status_code. That's the same call ShowExceptions and DebugExceptions use, so it honours config.action_dispatch.rescue_responses (RecordNotFound → 404, ParameterMissing → 400, anything else → 500) and unwraps ActionView::Template::Error the way Rails does, on every Rails version.
• The gem silences DebugExceptions' own logging and logs the error row from its ErrorEvent middleware instead. That middleware now honours config.action_dispatch.log_rescued_responses = false (Rails 7.0+) like DebugExceptions does, through the same request env key: no error row for rescued responses such as RecordNotFound. The response row with the 404 is still logged.
• ErrorEvent's own logging can no longer replace the app's exception: a StandardError while building or writing the error row goes to Logtail::Config.instance.debug, and the original exception is always re-raised. This is local to ErrorEvent, so the PR only needs the new rack API.

Behaviour and compatibility:

• Every request whose controller raises now produces a response row with the status the client receives, for example Completed 404 Not Found in 12.3ms.
• Error rows stay at level fatal, as before. Following config.action_dispatch.debug_exception_log_level is left out on purpose: load_defaults 7.1 sets it to :error, which would turn every exception row of most apps from fatal into error and break alerts on level = fatal.
• Apps that turned log_rescued_responses off stop getting error rows for rescued responses, matching their Rails logs. Nothing changes for apps that keep the default.
• To change the logged status for an exception class, use config.action_dispatch.rescue_responses, which the integration follows.

Targets the 0.2.15 patch release.

Depends on logtail-rack 0.2.9, which isn't released yet. The TEMP: run CI against the logtail-rack branch until 0.2.9 is released commit points the root Gemfile and every gemfiles/*.gemfile at the claude/response-on-exception branch of logtail-ruby-rack, so CI runs against the real API. The gemspec floor isn't bumped here: at merge time, after logtail-rack 0.2.9 is released, the TEMP commit gets replaced by a follow-up commit that requires logtail-rack ~> 0.2, >= 0.2.9. Until then this must not be merged.

It also carries the "Expect real response durations in the request specs" commit that the other open logtail-rails PRs share, byte for byte: logtail-rack 0.2.8 times responses with the monotonic clock, which Timecop doesn't freeze, so the three specs expecting 0.0ms now fail against the released rack too.

The first commit only adds the tests and is expected to fail on CI; the TEMP commit and the fixes come after it.

🤖 Generated with Claude Code