Skip to content
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

Merged
merged 1 commit into from Mar 26, 2021

Conversation

glasser
Copy link
Member

@glasser glasser commented Mar 26, 2021

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, 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
fixing.

Add some tests of this behavior and fix some TypeScript issues in the test file.

@glasser glasser requested a review from abernix March 26, 2021 04:34
@glasser glasser force-pushed the glasser/redact-all-startup-errors branch from 081ff9e to cde6656 Compare March 26, 2021 04:43
@@ -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(
Copy link
Member Author

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.

Copy link
Member Author

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.

@glasser glasser force-pushed the glasser/redact-all-startup-errors branch from cde6656 to 648aa2a Compare March 26, 2021 04:47
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.
@glasser glasser force-pushed the glasser/redact-all-startup-errors branch from 648aa2a to 285c5a5 Compare March 26, 2021 04:49
Copy link
Member

@abernix abernix left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@glasser glasser enabled auto-merge (squash) March 26, 2021 04:51
@glasser glasser disabled auto-merge March 26, 2021 04:55
@glasser glasser merged commit 3ae2f5f into main Mar 26, 2021
@glasser glasser deleted the glasser/redact-all-startup-errors branch March 26, 2021 04:55
glasser added a commit that referenced this pull request Mar 26, 2021
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.
@peterp
Copy link

peterp commented Mar 27, 2021

We're seeing a bunch of errors when trying to start the apollo-server-lambda in RedwoodJS.

api | Error: called start() with surprising state invoking serverWillStart
api |     at ApolloServer.<anonymous> (/Users/peterp/v0280/node_modules/apollo-server-core/src/ApolloServer.ts:510:13)
api |     at Generator.next (<anonymous>)
api |     at /Users/peterp/v0280/node_modules/apollo-server-core/dist/ApolloServer.js:8:71
api |     at new Promise (<anonymous>)
api |     at __awaiter (/Users/peterp/v0280/node_modules/apollo-server-core/dist/ApolloServer.js:4:12)
api |     at ApolloServer._start (/Users/peterp/v0280/node_modules/apollo-server-core/dist/ApolloServer.js:226:16)
api |     at ApolloServer.<anonymous> (/Users/peterp/v0280/node_modules/apollo-server-core/src/ApolloServer.ts:594:12)
api |     at Generator.next (<anonymous>)
api |     at /Users/peterp/v0280/node_modules/apollo-server-core/dist/ApolloServer.js:8:71
api |     at new Promise (<anonymous>)

Pinning the apollo-server-core back to 2.21.2 resolves the problem: 2.22.1 and 2.22.0 exhibit the same error.

@glasser
Copy link
Member Author

glasser commented Mar 29, 2021

Thanks @peterp for the report. I'll continue this discussion over at #5066 which you opened.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 16, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants