fix(fullstack): honor HTTP status in tuple FromResponse impls#5640
Open
kyle-rader-msft wants to merge 2 commits into
Open
fix(fullstack): honor HTTP status in tuple FromResponse impls#5640kyle-rader-msft wants to merge 2 commits into
kyle-rader-msft wants to merge 2 commits into
Conversation
The `(A, B)` and `(A, B, C)` `FromResponse` implementations ignored the
HTTP status code and always tried to decode the body as the success
type. When a server function returned a tuple such as
`(SetHeader<SetCookie>, Json<T>)` with a non-2xx status and an
`ErrorPayload`, the body was deserialized as `T`, surfacing a
`RequestError::Decode(..)` instead of the intended
`ServerFnError::ServerError { .. }`.
Check `status.is_success()` first and, on failure, parse the
`ErrorPayload` and return `ServerFnError::ServerError { message, code,
details }`, matching the single-type `FromResponse` behavior. This lets
clients recover typed errors from `details` for tuple responses just as
they already can for non-tuple responses.
Add tests for the `(A, B)` and `(A, B, C)` `FromResponse` impls covering both the 2xx success path and the non-2xx `ErrorPayload` path, mirroring the existing single-type `FromResponse` tests. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
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
2 participants
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
Fix the tuple
FromResponseimplementations for(A, B)and(A, B, C)indioxus-fullstackso they honor HTTP status codes, matching the existing single-typeFromResponsebehavior.When a server function returns a tuple such as
(SetHeader<SetCookie>, Json<T>)and the server responds with a non-2xx status carrying anErrorPayload, the previous tuple implementations would:T, producingRequestError::Decode(..)instead ofServerFnError::ServerError { details: .. }.This change checks
status.is_success()in the tuple impls and, on failure, parsesErrorPayload<serde_json::Value>and returnsServerFnError::ServerError { message, code, details }. Clients using typed error enums (deserialized fromdetails) can now reliably recover their custom error types for tuple server-function responses, just as they already can for non-tuple responses.Testing
cargo test -p dioxus-fullstack --testspasses locally (rustc 1.94.0).ErrorPayloadpath for both(A, B)and(A, B, C), mirroring the existing single-typeFromResponsetests.cargo clippy -p dioxus-fullstack --tests --all-features -- -D warningsandcargo fmt -- --checkare clean.Notes
Supersedes #5342, which was opened from a personal fork. The original fix is preserved here (rebased onto the latest
main) with added test coverage. The previous PR can be closed in favor of this one.