4.3.10 is a major breaking change in behavior

[alexanderbh]

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.

45edbfa

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.

[github-actions]

🎉 This issue has been resolved in version 4.3.11 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[yeiniel]

thank you @brett-vendia and @alexanderbh for fixing this situation so soon.

[lafiosca]

Not trying to dig up an ancient thread, but I upgraded from the old aws-serverless-express library to this one and had my API broken by this change. In my API Gateway config, I have / and /{proxy+} which both have Cognito auth configured and /public/{proxy+} which does not require any auth. All three of these paths point to the same Express Lambda. The old library preserved the paths, and in my Express app I knew not to expect authentication headers in any routes under /public/. But with this library now, requests to /public/stats show up as requests for /stats to the Express app. I guess to make this work without completely reconfiguring my API Gateway I will need to either build a custom request mapper or locally patch the library.

--
Edited to add: turns out the custom mapper is a bit of a hassle, probably easier to just delete event.pathParameters before passing the event to the handler. 🙃 Thinking about this more deeply, it seems silly to me to replace the path with the value of event.pathParameters.proxy by default. That's just a specific route parameter value that comes from the convention of having a catch-all route parameter named proxy. It conveys nothing about how the developer wants to map those routes to their Lambda function(s).

[eran-medan]

Not trying to dig up an ancient thread, but I upgraded from the old aws-serverless-express library to this one and had my API broken by this change. In my API Gateway config, I have / and /{proxy+} which both have Cognito auth configured and /public/{proxy+} which does not require any auth. All three of these paths point to the same Express Lambda. The old library preserved the paths, and in my Express app I knew not to expect authentication headers in any routes under /public/. But with this library now, requests to /public/stats show up as requests for /stats to the Express app. I guess to make this work without completely reconfiguring my API Gateway I will need to either build a custom request mapper or locally patch the library.

-- Edited to add: turns out the custom mapper is a bit of a hassle, probably easier to just delete event.pathParameters before passing the event to the handler. 🙃 Thinking about this more deeply, it seems silly to me to replace the path with the value of event.pathParameters.proxy by default. That's just a specific route parameter value that comes from the convention of having a catch-all route parameter named proxy. It conveys nothing about how the developer wants to map those routes to their Lambda function(s).

Having the same exact issue, I think we should reopen / create a new issue for this.