ruby-grape / grape / 35441540097

100%

push

github

Lint every response of an API once under lint! (#2960)

`lint!` and Grape.config.lint put Rack::Lint in each endpoint's stack, so
two kinds of response never met it: the 404 the router answers for a path
nothing matches, which no endpoint builds, and a Rack app mounted with
`mount`, which the router calls directly instead of through a stack. That
is how a HEAD request for an unknown path answered with a body (#2958)
while the suite, which lints every API, stayed green.

The per-endpoint Rack::Lint is gone. A linted API instead wraps its router
in a single Rack::Lint, which checks every response the API gives --
endpoints, errors, the router's own 404, mounted Rack apps -- exactly once,
and after Rack::Head, so a HEAD response is checked with its body stripped.
Keeping the endpoint Lints and adding one around the router would nest
two, and nested Rack::Lints cannot survive a middleware that calls `to_ary`
on the body -- the inner one closes it, the outer one then iterates it --
which Rack::ETag does in any Rails app mounting the API.

`lint!` is therefore read from the top of the API that is served, as the
README describes it ("at the API level"). Declared inside a namespace, or
in an API mounted into another one, it no longer does anything; README and
UPGRADING say so.

The suite's own lint then flagged two fixtures: `API.call({})`, an env
Rack::Lint rejects, and a mounted Rack app returning a frozen headers Hash,
which Rack 3 forbids. The first now passes a real env; the second an
unfrozen Hash the spec still checks is not written into.

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

1430 of 1485 branches covered (96.3%)

Branch coverage included in aggregate %.

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

4273 of 4273 relevant lines covered (100.0%)

28482.85 hits per line