Repository navigation
fix(openapi): use the error type's bad_request_handler in Result responses - #1230
Merged
attila-lin merged 1 commit intoOct 22, 2026
Merged
Conversation
…onses `impl ApiResponse for Result<T, E>` only looked at `T` for a custom bad request handler, so a handler declared on the error type was never called and the default 400 response was returned instead. Report a handler when either side has one. `T`'s handler still wins when both define one, so existing APIs keep their current behaviour. Fixes #967 Co-Authored-By: Claude Opus 5.5 <[email protected]>
Collaborator
|
Thanks @b84330808! Small, focused fix for #967 with good tests covering both precedence cases. Merging 🎉 |
1 of 2 tasks
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.
Fixes #967
If an operation returns
Result<T, E>and onlyEhas#[oai(bad_request_handler = "...")], the handler is never called. A missing or invalid parameter gets the default 400 response instead.The cause is
impl ApiResponse for Result<T, E>: it setsBAD_REQUEST_HANDLERfromTonly, andfrom_parse_request_erroralways buildsOk(T::...).This change reports a handler when either side has one. When
Thas none, the error goes toE's handler and comes back asErr. When both have one,Tstill wins, so existing code behaves the same.poem::Result<T>is unaffected becausepoem::Errorhas no handler.I added a test in
tests/api.rsfor a missing parameter, a failed validator, and the case where both types have a handler. I also added a line to the poem-openapi changelog.I used Claude Code to write this change.