-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
debug_handler: Check IntoResponseParts / IntoResponse for return tuple element types #2173
Comments
Is anyone working on this? I'd like to implement this if not. |
I don’t think so. You’re welcome to submit a PR! |
Thanks for the opportunity!
to
It checks the I'll start to add tests if you guys think this is a good approach. |
That sounds good, but I think for the extractors we also have special checks for Json and other body extractors of known names where we then print a custom error message if they're not last. Those kinds of messages would be helpful here as well, I think. |
Yes I agree that would be good but not essential and a PR without is also cool. We can always add that later. |
I was having the same thought when writing it, but I'm not sure what types should always be placed at last.So I added a //todo |
Added special checks for known types that implements IntoResponse but not IntoResponseParts, but it only checks for Json and String now , the list can be extended. |
Sorry this is my first time doing a pull request. Should I request a specific reviewer, or just leave it like that? |
Nope you don’t need to do anything. I’ll take a look this week :) |
Got it, thanks! |
In Jon Gjengset's Decrusting the axum crate video, he tried using
#[debug_handler]
to get a more useful error message for(StatusCode, Json<_>, AppendHeaders<_>)
not implementingIntoResponse
as part of a handler, but that didn't work. I think we can make it work.The text was updated successfully, but these errors were encountered: