Answer cascade false from the cascade reader for a version that does not cascade

[ericproulx]

The cascade reader and the compiled API each worked out whether an API cascades, and they disagreed:

class A < Grape::API
  version 'v1', using: :header, vendor: 'x', cascade: false
end

A.cascade              # => true
A.compile!.cascade?    # => false, and responses lose X-Cascade

API::Instance#resolve_cascade used the cascade DSL's value, then the cascade: option of version, then true. DSL::Routing#cascade skipped version and went straight to true.

Change

• The reader holds the one resolution: the value given to cascade, else version's cascade:, else true.
• The compiled API reads it there (self.class.cascade), and resolve_cascade is gone. It is still read once, in the constructor.

Tests

• .cascade specs: a version declared with cascade: false reads back false, and a later cascade true still wins over it. The first fails on master.
• The two "does not cascade" request specs checked last_response.headers.keys for 'X-Cascade'. Rack 3 lowercases header names, so they passed whatever the response carried. They now read headers['X-Cascade'], like the "cascades" specs next to them.

Mutation-checked: dropping the version fallback fails the new reader spec and the version request spec. A compiled API that ignores the reader fails both request specs. Before the spec fix, neither mutation failed a request spec.

🤖 Generated with Claude Code

[github-actions]

Danger Report

No issues found.

View run