Calling Lambda from CF Worker suddenly not working?

Developers Cloudflare Workers
1

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.

1 Like
2

This has popped up on google: After add lambda function in x-amazon-apigateway-integration, don't have access to run test on AWS console · Issue #9 · amazon-archives/aws-apigateway-importer · GitHub

Change the http method on your integration to POST and this should work.

Are you sending a POST or GET request?

3

POST :slight_smile:
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.

This is the function calling Lambda:

    function sendToLambda(awsbody, lambda, fnc = '/writeMetrics', region = 'eu-central-1')
  {
    const fn = fnc;
    const req = aws4.sign({
      method: 'POST',
      service: 'lambda',
      region: region,
      path: `/2015-03-31/functions${fn}/invocations/`,
      body: JSON.stringify(awsbody)
    }, credentials);

    return fetch(`https://${req.hostname}/${req.path}`, {
      method: req.method,
      headers: req.headers,
      body: req.body
    });
  }

This also hasn’t changed for months and suddenly stopped working (but only for external requests).

4

Hi @cat24max,

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.

Harris

2 Likes
5

Thanks @harris, you are awesome :slight_smile:

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?

Tim

6

Thanks for the kind words @cat24max!

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.

Harris

1 Like