Hey,
I am calling several Lambda functions from my Worker, the code has worked for a few months and millions of executions.
Since Thursday 11PM UTC my Worker stopped execution Lambda functions.
Right now the answer from Amazon is:
Unable to determine service/operation name to be authorized
The interesting thing is, if I run the same request interneally over the Workers debug console the requests works without any issue. How is this even possible? Same parameters, same headers… Makes no sense.
POST
This is like the only thing you find about this error on Google. And that the same code is working from within the Workers debug console makes no sense.
The issue is likely the extra ‘/’ in ${req.hostname}/${req.path} (according to the code you posted, req.path already begins with a ‘/’).
This is not your fault; it is ours. Up until our most recent release, our URL parser in fetch() collapsed consecutive ‘/’ characters in URL paths in a misguided effort to be helpful. This behavior was buggy and did not conform to the Fetch specification, and multiple people reported this to us.
Unfortunately, fixing the bug has broken existing scripts which inadvertently relied on it, and it appears that yours was among them. I am very sorry about this. It’s not acceptable for us to break existing, working scripts, and we are implementing a process to ensure that future changes cannot do so.
I almost gave up my “cheap” Lambda gateway (at least until MySQL access is available :)) that I planned to use for all kinds of features.
This “double slash” is kind of my fault… But it was really confusing, because the test environment in the editor seems to still have an old release?
It’s definitely not your fault. It would not have been an issue had we not had the bug to begin with, and we should have identified a reasonable migration path when fixing it.
You’re right that the preview service still has the old behavior – this will be updated with our release this week (probably today), at which point the URL parsing in fetch() will again behave the same in the preview and in production.
Note that the URL class does still collapse consecutive ‘/’ characters when parsing. We’ll have to fix this, too, but we’ll be doing so with a lot more caution.