Skip to content
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

Conflicting impl FromRequestParts and OptionalFromRequestParts #3134

Closed
1 task done
sebadob opened this issue Jan 1, 2025 · 3 comments
Closed
1 task done

Conflicting impl FromRequestParts and OptionalFromRequestParts #3134

sebadob opened this issue Jan 1, 2025 · 3 comments

Comments

@sebadob
Copy link

sebadob commented Jan 1, 2025

  • I have looked for existing issues (including closed) about this

Bug Report

Version

Latest axum-0.8 after upgrade from 0.7.

Platform

Fedora 41, but does not matter in this case.

Crates

Latest axum-0.8 + extras.

Description

Not sure if this is a bug or actually working as intended. I just upgraded from 0.7 to 0.8 and have some issues with the new OptionalFromRequestParts.

The issue is, that both of them can't be implemented at the same time for a given struct, since they both implement fn from_request_parts() which ends up in a conflict with multiple from_request_parts found. The issue is, that I need a non-optional extractor in lots of endpoints and an Option<_> in just very few and I don't really get it, how I should resolve this issue now. The only solution I can think of is duplicating the whole struct and create a new one with Optional appended and lots of boilerplate and conversion impl's.

Is there anything I did miss about how I can do this with v0.8? I ran into the issue with a custom struct Session for now, but will have the same problem in some other cases as well further down the road.

Edit:

Sorry I just saw that not the trait itself throws this error, but a

TypedHeader::<Authorization<Bearer>>::from_request_parts(parts, state)

inside the extractor. Will have a 2nd look at where this is coming from.

@sebadob
Copy link
Author

sebadob commented Jan 1, 2025

Sorry for the issue, it was my bad.

I was able to solve it by casting the TypedHeader to FromRequestParts manually.

@sebadob sebadob closed this as completed Jan 1, 2025
@jplatte
Copy link
Member

jplatte commented Jan 1, 2025

Instead of calling these trait methods directly, I'd recommend using RequestPartsExt, that would have avoided this issue. There's also an equivalent RequestExt.

@sebadob
Copy link
Author

sebadob commented Jan 1, 2025

Instead of calling these trait methods directly, I'd recommend using RequestPartsExt, that would have avoided this issue. There's also an equivalent RequestExt.

Thanks for the hint, will try that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants