Skip to content

Ensure startup errors are redacted even the first time#5064

Merged
glasser merged 1 commit into
mainfrom
glasser/redact-all-startup-errors
Mar 26, 2021
Merged

Ensure startup errors are redacted even the first time#5064
glasser merged 1 commit into
mainfrom
glasser/redact-all-startup-errors

Conversation

@glasser

@glasser glasser commented Mar 26, 2021

Copy link
Copy Markdown
Member

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
* updated as you upgrade Apollo Server.
*/
public async executeOperation(request: GraphQLRequest, integrationContextArgument?: Record<string, any>) {
public async executeOperation(

Copy link
Copy Markdown
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
Copy Markdown
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

@abernix abernix left a comment

Copy link
Copy Markdown
Member

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

peterp commented Mar 27, 2021

Copy link
Copy Markdown

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

glasser commented Mar 29, 2021

Copy link
Copy Markdown
Member Author

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.

3 participants