You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Multiple path parameters from tuple are ignored #113
When the path has multiple parameters, Axum supports two ways of passing them to the handler. First is to make a struct which is then parsed. This use case works well. Second is to accept it as tuple. Both cases presented in Axum documentation.
The tuple-based path is not handled properly by Aide. I have made a small change to the example to demonstrate the issue.
I defined two new handlers using both approaches. The function depends_on_todo_struct has its OpenAPI spec as follows
"/todo/{id}/depends-on-with-struct/{depends_on_id}": {
"put": {
"description": "Todo depends on another Todo.",
"parameters": [
{
"in": "path",
"name": "depends_on_id",
"description": "The ID of the Todo that this Todo depends on.",
"required": true,
"schema": {
"description": "The ID of the Todo that this Todo depends on.",
"type": "string",
"format": "uuid"
},
"style": "simple"
},
{
"in": "path",
"name": "id",
"description": "The ID of the Todo.",
"required": true,
"schema": {
"description": "The ID of the Todo.",
"type": "string",
"format": "uuid"
},
"style": "simple"
}
],
"responses": {
"...": "..."
}
}
},
The function is missing the parameters field completely
"/todo/{id}/depends-on/{depends_on_id}": {
"put": {
"description": "Todo depends on another Todo.",
"responses": {
"...": "..."
}
}
},
As far as I remember I left this out intentionally as tuples don't contain name information for parameters and the schema generation is decoupled from the path itself.
That being said it could be possible to support this in some way during generation, we would have to parse the path to look for parameters and adjust the schemas accordingly, I'm not sure if it's worth the effort but I'm not against it if it's doable without a major bump in complexity.
Understood. I'd suggest to at least change the current behaviour. At the moment it fails silently which is less than ideal. I've spent unreasonable amount of time chasing this one (it showed up on the client-side after code-generator which also had a related bug 🤦). Perhaps just fail the whole compilation with a way to override the failure?
Opened #299 that should fix this. It infers path parameters from the extractor type, so e.g. Path<(Uuid, u64)> becomes two parameters in order with the matching types.
Activity
tamasfe commentedon Feb 13, 2024
As far as I remember I left this out intentionally as tuples don't contain name information for parameters and the schema generation is decoupled from the path itself.
That being said it could be possible to support this in some way during generation, we would have to parse the path to look for parameters and adjust the schemas accordingly, I'm not sure if it's worth the effort but I'm not against it if it's doable without a major bump in complexity.
tomas789 commentedon Feb 13, 2024
Understood. I'd suggest to at least change the current behaviour. At the moment it fails silently which is less than ideal. I've spent unreasonable amount of time chasing this one (it showed up on the client-side after code-generator which also had a related bug 🤦). Perhaps just fail the whole compilation with a way to override the failure?
iftachFridental commentedon Sep 11, 2024
any update? having the same issue
esmevane commentedon Apr 10, 2025
Some docs or advice about
Path<T>(and some other axum newtypes) would be nice. @tamasfe would you be alright with PRs adding some?feat: deposit confirm modal functionality (tamasfe#113)
hniksic commentedon Apr 24, 2026
Opened #299 that should fix this. It infers path parameters from the extractor type, so e.g.
Path<(Uuid, u64)>becomes two parameters in order with the matching types.