-
Notifications
You must be signed in to change notification settings - Fork 254
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Running Gateway on AWS Lambda hits socket errors when loading managed schema #949
Comments
Same error here, we had to add |
I also have the same error. |
Same error for me, running on Node 14 |
Same here - it works well for a while and that it breaks down. But afterwards runs for days. |
any updates on this from the team? I am getting this error constantly
|
Just to add my findings to this as well. MFH will not retry on post methods and that is what is being used when fetching the remote SDLs from the subgraphs with federation. Even with retries you could still find yourself in this strange state that occurs when the failure happens. So adding retries is not a silver bullet. |
I run
@apollo/gateway@^0.36.0
on AWS Lambda and it appears that the background Promise that fetches managed schema fromuplink.api.apollographql.com
can fail, putting the entire server on the lambda in a bad state. The only way this resolves itself is when the Lambda cools off and gets destroyed.The errors that I observe in logs are:
This data graph is missing a valid configuration. More details may be available in the server logs.
An error occurred during Apollo Server startup. All GraphQL requests will now fail. The startup error was: An error occurred while fetching your schema from Apollo: request to https://uplink.api.apollographql.com/ failed, reason: Client network socket disconnected before secure TLS connection was established
Note: I've seen reasons
This mainly seems to happen when the lambda experiences an error (e.g. throwing AuthenticationError in
context
, an query result validation error or even a lambda timeout).I was partially able to mitigate this providing a
fetcher
toApolloGateway
to force theconnection: close
header to prevent connection reuse. Despite this change, the error still happens. My current working theory is that the background Promise to load the managed schema is running when the Lambda is frozen (because callbackWaitsForEmptyEventLoop is set to false)https://docs.aws.amazon.com/lambda/latest/dg/nodejs-context.html
It appears that this may be a bug with AWS Lambda itself: aws/aws-sdk-js#3591
Given that Lambda can freeze when the client response is complete (and we shouldn't delay the client response to refresh the managed schema), does it make sense to turn off the refresh mechanism in Lambda or implement it as a CI/CD step?
The text was updated successfully, but these errors were encountered: