ruby-grape / grape / 33382241712

97%

master: 97%

Pull #2878

github

Build an error response's backtrace only when it will be rendered

Every error response materialized the exception's backtrace.
`ErrorResponse.from_exception` read `exception.backtrace` to store it, and
`Middleware::Error#error_response` re-derived it with
`raw.backtrace || raw.original_exception&.backtrace || []`.

`Exception#backtrace` is not a field read: it converts the captured frames into
an Array of location Strings, one per frame, and a Grape error is raised deep
inside the validation stack. Meanwhile every built-in error formatter drops the
result unless the API asked for it:

    wrapped_message[:backtrace] = error.backtrace if include_backtrace && ...

and `include_backtrace` is `rescue_from ..., backtrace: true`, off by default.
So the common 400 paid to build a backtrace that was then discarded.

`from_exception` no longer reads it — the exception travels on the payload as
`original_exception`, so nothing is lost — and `error_response` assembles one
only when `include_backtrace` is set.

On a small API answering a validation failure (400 Bad Request), median of 9
interleaved runs, Ruby 4.0.5 with YJIT:

    8,749 -> 11,878 req/s   (+36%)
    333 -> 266 objects per request

`rescue_from ..., backtrace: true` and `original_exception: true` render exactly
as before; the specs covering both are unchanged.

A custom error formatter that reads `error.backtrace` while ignoring the
`include_backtrace:` argument it is passed now receives an empty Array. It still
has `error.original_exception` and can call `#backtrace` on that itself. See
UPGRADING.

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

1238 of 1332 branches covered (92.94%)

Branch coverage included in aggregate %.

3 of 3 new or added lines in 1 file covered. (100.0%)

3900 of 3968 relevant lines covered (98.29%)

27145.18 hits per line