question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

didEncounterErrors and willSendResponse are not called on AuthenticationError

See original GitHub issue

Using apollo-server-express 2.12.0.

According to this lifecycle, willSendResponse should always be called, and didEncounterErrors should at least be called if there’s an error:

https://www.apollographql.com/docs/apollo-server/integrations/plugins/#request-lifecycle-event-flow

However, we’re only seeing requestDidStart being called, and nothing more, if we have an authentication error. We’re using graphql-shield 7.2.6 for our authorization. The response is returned to the client, but willSendResponse is never called (and nor is didEncounterErrors).

Eg, given the following:

const server = new ApolloServer({
  plugins: [
    {
      requestDidStart() {
        console.log('requestDidStart')
      },
      parsingDidStart() {
        console.log('parsingDidStart')
      },
      didEncounterErrors() {
        console.log('didEncounterErrors')
      },
      willSendResponse() {
        console.log('willSendResponse')
      },
    },
  ],
  // ...

All we see output in our logs is:

requestDidStart

And we get a valid response with an errors array with message, location, stacktrace, etc all looking as they should for an authentication error.

So neither parsingDidStart nor willSendResponse is invoked – somehow these are bypassed, which indicates there’s either a bug, or the lifecycle is not accurately documented.

Issue Analytics

  • State:closed
  • Created 3 years ago
  • Comments:10 (1 by maintainers)

github_iconTop GitHub Comments

14reactions
trevor-scheercommented, May 1, 2020

Hey @mhart, please take a closer look at the examples in the docs. You’ll notice the API for a plugin is slightly different from how you’ve used it in your snippet.

requestDidStart is a function that returns an object of the other hooks you’re looking to use. This allows plugins to maintain a local context or scope during the course of a request that the other hooks can consume.

I believe what you really want is this:

const server = new ApolloServer({
  plugins: [
    {
      requestDidStart() {
        console.log('requestDidStart');
        return {
          parsingDidStart() {
            console.log('parsingDidStart')
          },
          didEncounterErrors() {
            console.log('didEncounterErrors')
          },
          willSendResponse() {
            console.log('willSendResponse')
          },
        };
      },
    },
  ],
  // ...

@trickleup does this apply to you as well or are you experiencing the issue differently? Please provide a reproduction if you think there’s a bug that needs to be addressed. Thanks!

1reaction
trickleupcommented, May 1, 2020

Thanks @trevor-scheer! Yes, with your example the didEncounterErrors hook does fire for the persisted query exceptions. My bad, thanks for clarifying!

Read more comments on GitHub >

github_iconTop Results From Across the Web

Error handling - Apollo GraphQL Docs
A client sent the hash of a query string to execute via automatic persisted queries, but the query was not in the APQ...
Read more >
How to Only Catch non-ApolloError Errors with Apollo ...
The solution is to check whether err.originalError (not err ) is an instance of ApolloError like this: if (err.
Read more >
GraphQL: Apollo Server Plugins in Typescript - Jeff Magnusson
In this case, parsingDidStart is not called for the request, ... The didEncounterErrors event fires when Apollo Server encounters errors while parsing, ...
Read more >
apollo-server-core | Yarn - Package Manager
This package implements the core logic of Apollo Server. It exports a base version of ApolloServer . Typically you do not use this...
Read more >
Why we considered Apollo for our GraphQL stack
Since it is not ideal to cache POST requests, it is often commented that ... The functionality defined in compossible units called “Links”...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found