URL dispatch depends on route registration order rather than convention

[vbakc]

Expected Behavior

URL dispatch works in the same way regardless of configuration order.

Current Behavior

If a handler with Path extractor is registered before the nested endpoint it will throw an error like this: cannot parse "ROUTE_URL" to a i64

Your Environment

• Rust Version (I.e, output of rustc -V): rustc 1.62.1 (e092d0b6b 2022-07-16)
• Actix Web Version: 4.2.1

[robjtede]

Can you show an example of a route and handler setup that is surprising to you?

[vbakc]

@robjtede sure.

pub fn configure_routes(config: &mut ServiceConfig) {
    config.service(
        scope("resource-name")
            .service(resource_name::index)
            .service(resource_name::nested_route)
    );
}

mod resource_name {
    #[get("/{id}/")]
    pub async fn index(id: Path<i64>) -> Result<impl Responder> {}

    #[get("/nested-route/")]
    pub async fn nested_route() -> Result<impl Responder> {}
}

[ilka-schulz]

I have the same problem. Actix's behavior is quite frustrating because it makes my app show unexpected behavior. I have hundreds of endpoints registered algorithmically so the solution to Actix's unconventional behavior is unfortunately not trivial for me...

[anhnguyensgu]

Hi guys. Any updates on this issue? I have the same problem.

[varshard]

Look like the issue is how actix store routes. It store routes in a vector and it will iterate through the route vector and return the first route that match. Hence the first registered route is matched first.

matchit is a URL router that can support this kind of behavior.

[MateSoftware2023]

i have same problem