Make the cascade DSL getter return the configured value#2827
Open
ericproulx wants to merge 1 commit into
Open
Conversation
`cascade` with no argument returned `!cascade.nil?` — i.e. whether cascading had been configured at all — so `cascade false` read back as true, contradicting the runtime behavior (Instance#cascade? correctly returns false). Return the stored value itself, or true when never set. Present since at least v2.4.0. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
ericproulx
force-pushed
the
fix-cascade-dsl-getter
branch
from
July 26, 2026 19:37
f23d314 to
7b3fa7d
Compare
Danger ReportNo issues found. |
dblock
approved these changes
Jul 27, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The
cascadeDSL getter doesn't return what was configured:!cascade.nil?answers "was cascade set to a non-nil value", not "does this API cascade". So:…while the runtime honors the setting correctly —
Grape::API::Instance#cascade?returnsfalseand theX-Cascadeheader is stripped. The getter simply contradicts the actual behavior it's supposed to report. The!value.nil?shape goes back at least to v2.4.0 (!namespace_inheritable(:cascade).nil?), so this is long-standing, not a recent regression.Fix
Return the stored value when one was configured,
true(the documented default) otherwise:The getter now always agrees with
Instance#cascade?for every configured value, including the degeneratecascade nilcase (both report falsy — previously the getter saidfalsewhile meaning "set to nil").Compatibility
Strictly speaking this changes a public getter's return value: anyone using
API.cascadeto detect "wascascadecalled at all" (rather than its meaning) would seefalseinstead oftrueaftercascade false. Since the next release is 4.0.0, this lands with an UPGRADING note; the existing.cascadespec is extended to cover unset /true/false.🤖 Generated with Claude Code