What exactly is meant by "We choose the most explicit registered route that matches an incoming event."?

[dmarra]

In the documentation, it is stated in the section about catch-all routes the following:

We choose the most explicit registered route that matches an incoming event.

I understood this to mean that in the case where a more specific match is found, that it will pick the more explicit match over the other. For instance:

@app.get(".+")
def catch_all():
    pass

@app.get("/my/resource/<resource_id>")
def more_explicit():
    pass

In this case, I would think from the docs that a request to /my/resource/12345 would invoke more_explicit, but in practice I see the opposite happen (catch_all is invoked for everything).

I am wondering if I misinterpreted the docs, or if there is some other issue in my own code that I am overlooking. Really a sanity check here.

[leandrodamascena]

Hello @dmarr, We are discussing an improvement to our documentation in this issue: #2962. This case you brought may even be a bug, I need to investigate further.

What do you think about adding your thoughts and findings there so we can create a PR to fix/improve our documentation and even bugs if any?

Thank you.

[dmarra]

I would be happy to move this to there. i'll do that today

[heitorlessa]

Could you move the catch all route to be defined last in your code and try again plz? **Reasoning** That’s because routes are registered in the order they are defined - we split static from dynamic routes to find the most specific (along with dynamic args) In this case, both routes are dynamic. As such, catch all route is always triggered before any route has a chance for a match. It’d be great to hear what your intent is. I assume you’d want to have a route to fallback to, e.g., custom 404 response (we do by default but you may have your reasons). **Next** As Leandro suggested. We should add a safeguard in the apigateway.py to detect whether a catch all route like this was registered, so we try for a match as a last option (assuming that’s the original intent here).

…

On Fri, 18 Aug 2023 at 22:39, Leandro Damascena ***@***.***> wrote: Hello @dmarr <https://github.com/dmarr>, We are discussing an improvement to our documentation in this issue: #2962 <#2962>. This case you brought may even be a bug, I need to investigate further. What do you think about adding your thoughts and findings there so we can create a PR to fix/improve our documentation and even bugs if any? Thank you. — Reply to this email directly, view it on GitHub <#2976 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZPQBADX6S5HAYGYACEMFDXV7HHPANCNFSM6AAAAAA3V6ZPZI> . You are receiving this because you are subscribed to this thread.Message ID: <aws-powertools/powertools-lambda-python/repo-discussions/2976/comments/6765035 @github.com>

[dmarra]

Could you move the catch all route to be defined last in your code and try
again plz?

I had already tried this when I noticed the ordering while stepping through the code, and it still picked the broader scoped rule over the better defined one unfortunately.

My use case is to place an api gateway in front of a (very) legacy application in a private subnet. what I wanted to do is simply forward the requests more or less as is. thats the gist of it. So my idea was to just use the catch-all for most of my endpoints, and more specific ones for cases where I need alternative rules.

My workaround for this ended up being using the not_found decorator, which feels kinda dirty, but it provides the functionality I need in the meantime.

I'll move the original discussion to #2962

[leandrodamascena]

Hello @dmarra! Thank you for adding comments on issue #2962. I will close this discussion as completed and will update progress on the issue.