Summary

Fix tuple FromResponse implementations for (A, B) and (A, B, C) in dioxus-fullstack so they honor HTTP status codes.

When a server function returns a tuple like (SetHeader<SetCookie>, Json<T>) and responds with a non-2xx status and an ErrorPayload, the previous implementation would:

• Ignore the HTTP status, and
• Attempt to deserialize the error body as T, producing RequestError::Decode(..) instead of ServerFnError::ServerError { details: .. }.

This change checks status.is_success() in the tuple FromResponse impls and, on failure, parses ErrorPayload<serde_json::Value> and returns ServerFnError::ServerError { message, code, details }, matching the single-type FromResponse behavior.

This allows clients using typed error enums (deserialized from details) to reliably recover their custom error types for tuple server function responses, just like they already can for non-tuple responses.

Testing

• cargo test -p dioxus-fullstack --tests passes locally, including the existing request::test::* tests.
• Verified in an external app that tuple responses like (SetHeader<SetCookie>, Json<T>) now surface ServerFnError::ServerError instead of Request(Decode(..)) on non-2xx responses, enabling correct deserialization of custom error types from details.

Made with Cursor