4.3.10 is a major breaking change in behavior

4.3.10 is breaking ALL our services. It is a patch version and we they are updated automatically. Why is this change not a major version bump? It might have fixed an “issue”. But if the issue is how everyone have setup their existing routes then fixing this is a breaking change.

https://github.com/vendia/serverless-express/commit/45edbfa79bac97ce3429dda68add5ee16ab45d5b

It might “error out with 404” if you are setting up a new service. But for everyone else using this library. And have routes that works. This will totally mess it up.

In my event handler I have staff/admin/{proxy+} and in my serverless-express server I have a route that simply matches on for example /list. That works great in 4.3.9 or below. That is how everyone have managed until now. It will match the path staff/admin/list. Great.

It might “error out with 404” if you make your route like /staff/admin/list. But you have to think about existing users. We are using 4.3.9 as it is. Changing this “issue” (I like it better if I can just route on the proxy part alone so it is not an improvement for me) breaks it for everyone using proxy on 4.3.9.

@selvendranayyaswamy @selvendran.ayyaswamy

[yeiniel]

i’m facing the same issue @alexanderbh is facing right now

if you have staff/admin/{proxy+} at your SAM template it doesn’t make sense to use /staff/admin/list at the lambda code level. That means that your lambda can’t be setup to handle a different event on a different path. Your lambda code should be agnostic of the mount path you are using on the Api Gateway

[alexanderbh]

i’m facing the same issue @alexanderbh is facing right now

if you have staff/admin/{proxy+} at your SAM template it doesn’t make sense to use /staff/admin/list at the lambda code level. That means that your lambda can’t be setup to handle a different event on a different path. Your lambda code should be agnostic of the mount path you are using on the Api Gateway

Exactly this. We have the same lambda function on different API Gateway proxy endpoints. We have one that has an authorizer called staff/admin/list. But then we have another resource on API gateway that is pointing to the SAME lambda function. But it does not have an authorizer (or it could be a different one). In our case we have some manual header authentication. That resource is called staff/internal/list. But they are both pointing to the same lambda function.

But now I cannot make a single lambda listening for the proxy part (/list) and use it both places. Now the lambda is forever bound to the exact path prefix for the custom domain + what ever URL path you have used in the API Gateway resource.

That lambda function is just listening for the proxy part: /list. It does (and should) not care about the path leading up to it.