Keep a String error message's status when the route names a failure entity - #2953
Open
ericproulx wants to merge 1 commit into
Open
ericproulx wants to merge 1 commit into
ericproulx wants to merge 1 commit into
Conversation
ericproulx
force-pushed
the
fix/failure-entity-string-message
branch
from
September 18, 2026 09:37
022b272 to
872d6ef
Compare
Danger ReportNo issues found. |
ericproulx
force-pushed
the
fix/failure-entity-string-message
branch
from
September 18, 2026 10:24
872d6ef to
b2e5dec
Compare
…ntity
ErrorFormatter::Base#present applies the entity a route's failure codes
name for the response status to whatever error! was given. An entity
exposing attributes cannot read any off a String, so error!('Unauthorized',
401) under `failure: [[401, 'Unauthorized', API::Error]]` raised while
rendering, and the failsafe answered 500 in place of the 401.
That has been true of the `failure` block method and the `http_codes:`
keyword for as long as they presented errors. #2949 made the `failure:`
keyword present too -- the spelling grape-swagger's README recommends -- so
on master an API that documents its 401 that way and calls error! with a
String turns every 401 into a 500.
The failure entities document a structured error body, and every README
example hands error! a Hash, so a String message is now left to
#wrap_message, which renders it the way it renders without an entity. A
Hash or an object is presented as before, and `with:` and a class's own
Entity are untouched.
An entity written to take the String itself is no longer handed one;
UPGRADING shows moving it to a Hash message.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
ericproulx
force-pushed
the
fix/failure-entity-string-message
branch
from
September 18, 2026 12:52
b2e5dec to
0e224d4
Compare
dblock
approved these changes
Sep 19, 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.
Summary
ErrorFormatter::Base#presentapplies the entity that a route'sfailurecodes name for the response status to whatevererror!was given. An entity that exposes attributes can't read any off a String, so this raises while rendering and the failsafe answers 500 in place of the requested status:The
failureblock method and thehttp_codes:keyword have always behaved this way. #2949 (unreleased) made thefailure:keyword present too, which is the spelling grape-swagger's README recommends (failure: [[401, 'KittenBitesError', Entities::BadKitten]]). So on master, an API that documents its 401 that way and callserror!with a String now gets a 500 for every 401. 4.0.1 answered 401.The failure entities document a structured error body, and every README example passes a Hash to
error!. A String message is therefore now left to#wrap_messageand renders the same way it does when no entity is declared. Hash and object messages are presented as before.with:and a class's ownEntityare untouched.error!given{ code: 'x', message: 'm' }'Unauthorized'(any of the three spellings){"error":"Unauthorized"}Backward compatibility
An entity written to take the String itself (
expose(:message) { |message, _| message }) and declared through the block method orhttp_codes:used to present String messages. It no longer receives them. UPGRADING shows moving it to a Hash message.Test plan
endpoint_spec.rbgains a String-message example. All three fail on master and pass here.spec/integration/grape_entity/entity_spec.rbcovers the same case with a realGrape::Entity. It fails on master and passes here.gemfiles/grape_entity.gemfile).🤖 Generated with Claude Code