apollo-server-lambda with async resolvers callback too early in lambda nodejs10x runtime

Created on 22 May 2019  ·  7Comments  ·  Source: apollographql/apollo-server

We've upgrade our lambda runtime to the nodejs10.x (from nodejs8.x). After doing this our resolvers started returning almost immediately without awaiting (e.g. they returned with a body of null).

We had been using the documented way of returning createHandler:

export const handler = server.createHandler({
  cors: { origin: '*' },
});

However now, as a workaround, we're using (as inspired by #2179):

import { ApolloServer } from 'apollo-server-lambda';
import resolvers from './resources/resolvers';
import typeDefs from './resources/typeDefs';

const server = new ApolloServer({
  typeDefs,
  resolvers,
  context: ({ event, context }) => {
    logger.debug(event);
    return { event, context };
  },
});

function runApollo(event, context, apollo) {
  return new Promise((resolve, reject) => {
    const callback = (error, body) => (error ? reject(error) : resolve(body));
    apollo(event, context, callback);
  });
}

export async function handler(event, context) {
  const apollo = server.createHandler({ cors: { origin: '*' } });
  const response = await runApollo(event, context, apollo);
  return response;
}

As an initial diagnostic it looks like the way server.createHandler tries to avoid breaking the previous contract by wrapping its async construction in a sync one no longer works in Node 10.

node: 10.15.3
apollo-server-lambda: 2.4.8

🖇️ lambda

Most helpful comment

Thank you for posting this. I was up till 4am last night trying to diagnose this issue. I thought it was me.

All 7 comments

Thank you for posting this. I was up till 4am last night trying to diagnose this issue. I thought it was me.

As some wider context, it looks like this is more likely to be on the side of AWS than Apollo. Although the workaround for creating server synchronously does still look like it might cause race conditions, the whole AWS Lambda Node 10 runtime seems like it has been rushed:

https://medium.com/@hichaelmart/reviewing-the-aws-lambda-nodejs10-x-runtime-84de1e500aac

Hopefully AWS will get these issues addressed soon and this workaround will no longer be needed.

It is most certainly on AWS side, however it would be nice if we had a solution until that gets fixed. Currently there's no published timeline for AWS to fix the Node 10.x Lambda runtime.

The fix for apollo-server-lambda could be as simple as updating the docs, or something more complicated in the code. Which approach would be most acceptable to the maintainers? I'm happy to contribute whichever solution is deemed most acceptable.

Is this fixed with the closing of awslabs/aws-serverless-express#234?

Taking that as a yes (feel free to reopen if not)

FWIW -- I just encountered this on the Lambda Node.js v14 runtime, and @thomasmichaelwallace's workaround worked for me.

Was this page helpful?
0 / 5 - 0 ratings