-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Ensure startup errors are redacted even the first time #5064
Conversation
081ff9e
to
cde6656
Compare
@@ -1270,7 +1274,10 @@ export class ApolloServerBase { | |||
* `{req: express.Request, res: express.Response }` object) and to keep it | |||
* updated as you upgrade Apollo Server. | |||
*/ | |||
public async executeOperation(request: GraphQLRequest, integrationContextArgument?: Record<string, any>) { | |||
public async executeOperation( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been keeping this particular file prettier-happy but failed to do so on a PR I merged today, sigh.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
eh I'll roll this part of the diff back. since I do want to cherry-pick this on top of the last release.
cde6656
to
648aa2a
Compare
This is a regression in #4981. If the server start process is begun implicitly by the execution of an operation (ensureStarted inside graphQLServerOptions) and startup throws, the log-and-redact logic wasn't being invoked. Note that this case doesn't usually happen in practice, because: - If you're using `apollo-server`, startup is begun in `listen()` before you can serve requests - If you're using a serverless framework integration, startup is begun in the constructor - If you're using a non-serverless framework integration, the function you call to connect it to your framework begins startup with `ensureStarting()` So mostly this just affects the case that you're running `executeOperation` without calling `start()` or `listen()`, or maybe you have your own custom framework integration that doesn't call `ensureStarting()`. But it's still worth missing. Add some tests of this behavior and fix some TypeScript issues in the test file.
648aa2a
to
285c5a5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
This is a regression in #4981. If the server start process is begun implicitly by the execution of an operation (ensureStarted inside graphQLServerOptions) and startup throws, the log-and-redact logic wasn't being invoked. Note that this case doesn't usually happen in practice, because: - If you're using `apollo-server`, startup is begun in `listen()` before you can serve requests - If you're using a serverless framework integration, startup is begun in the constructor - If you're using a non-serverless framework integration, the function you call to connect it to your framework begins startup with `ensureStarting()` So mostly this just affects the case that you're running `executeOperation` without calling `start()` or `listen()`, or maybe you have your own custom framework integration that doesn't call `ensureStarting()`. But it's still worth missing. Add some tests of this behavior and fix some TypeScript issues in the test file.
We're seeing a bunch of errors when trying to start the apollo-server-lambda in RedwoodJS.
Pinning the |
This is a regression in #4981. If the server start process is begun implicitly
by the execution of an operation (ensureStarted inside graphQLServerOptions)
rather than by an explicit start call (or the implicit start calls in
apollo-server
or the serverless integrations) and startup throws, thelog-and-redact logic wasn't being invoked.
Note that this case doesn't usually happen in practice, because:
apollo-server
, startup is begun inlisten()
before you canserve requests
constructor
to connect it to your framework begins startup with
ensureStarting()
So mostly this just affects the case that you're running
executeOperation
without calling
start()
orlisten()
, or maybe you have your own customframework integration that doesn't call
ensureStarting()
. But it's still worthfixing.
Add some tests of this behavior and fix some TypeScript issues in the test file.