Hit a bit of an issue with using a lambda function default authorizer on an ApolloApi stack. The first time I try to use the graph api, the request works. Subsequent times fail (500 response) until after a fixed period of time, in which case one more request works and then subsequent calls fail. After some digging around we worked out that setting the authorization cache TTL to 0 fixed this. However, we'd quite like to use the authorization caching so this seems like a temporary fix... I tried adding breakpoints in our code to work out where the 500 was coming from but it didn't hit any. The issue appears to be elsewhere but I've no idea where. A colleague of mine had a similar issue with a Serverless (non-SST) stack a while ago, which is how he thought to try this fix. He never worked out how to get around the issue without disabling the caching like this. Any idea how to get this working with SST?

Hey @Phil Astle, the default cache TTL for a Lambda authorizer is 0. Can I see how you are creating the Lambda authorizer?

It wasn't 0 for us when we created them - I think it was maybe 300? I didn't get to see the default value - just that it was a few minutes. We create the Apollo stack like this:

// Create a Apollo API
    const api = new ApolloApi(this, "Api", {
      cors: true,
      customDomain,
      defaultFunctionProps,
      defaultAuthorizationType,
      defaultAuthorizer,
      server: "graph-server.handler",
    });

where the authorization stuff is created like this:

defaultAuthorizationType = ApiAuthorizationType.CUSTOM;
      defaultAuthorizer = new HttpLambdaAuthorizer({
        authorizerName: "LambdaAuthorizer",
        resultsCacheTtl: Duration.seconds(0),
        handler: new sst.Function(this, "Authorizer", {
          handler: "src/graph/jwt-authorizer.handler",
          environment: {
            JWT_SECRET_ADMIN: process.env.JWT_SECRET_ADMIN || "",
            JWT_SECRET_INTERNAL: process.env.JWT_SECRET_INTERNAL || "",
          },
        }),
      });

We added resultsCacheTtl to get around the fact it wasn't set to 0 and caused crashes. What we would like to do is use the caching if possible though. Is that not supported by AWS/SST yet @Frank?

So if you don’t set

resultsCacheTtl

, it’s set to 300s?

I couldn't guarantee it was 300s but it definitely wasn't 0 until we added the resultsCacheTtl property with an explicit value of 0. Originally, we didn't include the property at all. We return an IAM policy.

Hey @Phil Astle, yeah I can confirm the default response cache ttl is 300s

Hey @Frank that's good to know - it means I hadn't managed to mess it up somehow! Thanks for looking more into it. We tried a few things out but just kept getting 500s. Our authoriser is pretty basic atm so no caching isn't too bad. It would be nice to use it though, just to do it properly! Plus if we have a more complicated authoriser at some point in the future, it'd be nice to know we have a solution. If there's anything I can do to help, please let me know.

Hey @Phil Astle, I added an example for Lambda authorizer with IAM response format. https://github.com/serverless-stack/serverless-stack/tree/master/examples/api-auth-lambda-authorizer-iam-response

Great! I'll try to check it out later today.