Skip to content

Multiple path parameters from tuple are ignored #113

Open

Description

@tomas789

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": {
          "...": "..."
        }
      }
    },

Activity

  1. tamasfe commented on Feb 13, 2024

    @tamasfe
    Owner

    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.

  2. tomas789 commented on Feb 13, 2024

    @tomas789
    Author

    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?

  3. iftachFridental commented on Sep 11, 2024

    @iftachFridental

    any update? having the same issue

  4. esmevane commented on Apr 10, 2025

    @esmevane

    Some docs or advice about Path<T> (and some other axum newtypes) would be nice. @tamasfe would you be alright with PRs adding some?

  5. hniksic commented on Apr 24, 2026

    @hniksic
    Contributor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions