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

Context in formatError #631

Closed
Christilut opened this issue Oct 23, 2017 · 10 comments · Fixed by #1547
Closed

Context in formatError #631

Christilut opened this issue Oct 23, 2017 · 10 comments · Fixed by #1547

Comments

@Christilut
Copy link

Any way to reach the context inside the formatError function? I couldn't find anything about it in the docs.

export const graphQlRoute = graphqlExpress(req => ({
  schema,
  context: {
    user: req.user
  },
  formatError
}))
@danny-larsen
Copy link

Any progress on this or a work around?

@martijnwalraven
Copy link
Contributor

martijnwalraven commented Dec 13, 2017

What is your use case for this?

As a workaround, you should be able to store the context as a local variable inside the closure. Something like:

export const graphQlRoute = graphqlExpress(req => {
  const context = {
    user: req.user
  };
  return {
    schema,
    context,
    formatError(error) {
      // access context here
    }
  }
});

@advance512
Copy link

This forces a re-evaluation of the formatError function on each request - kinda pointless.
I think you can define it outside of the request handler and still get access to the outer closure variables.

BTW, how can you get the variables? Part of the err.source.body?

@codyzu
Copy link

codyzu commented Aug 3, 2018

This doesn't seem possible with apollo-server-koa. When logging and reporting errors, I need to get some info from the request in order to create a relation between the errors and the requester.

Has anyone made any progress for this or found workaround that works with the apollo server integrations?

evans pushed a commit that referenced this issue Sep 8, 2018
* Pass the context along to all the extension methods

Addresses #1343 

With this change you should now be able to implement an extension like so:

```javascript
class MyErrorTrackingExtension extends GraphQLExtension {
    willSendResponse(o) {
        const { context, graphqlResponse } = o

        context.trackErrors(graphqlResponse.errors)

        return o
    }
}
```

Edit by @evans :
fixes #1343
fixes #614 as the request object can be taken from context or from requestDidStart
fixes #631 ""

* Remove context from extra extension functions

The context shouldn't be necessary for format, parse, validation, and
execute. Format generally outputs the state of the extension. Parse and
validate don't depend on the context. Execution includes the context
argument as contextValue

* Move change entry under vNext
abernix pushed a commit that referenced this issue Oct 10, 2018
* Pass the context along to all the extension methods

Addresses #1343

With this change you should now be able to implement an extension like so:

```javascript
class MyErrorTrackingExtension extends GraphQLExtension {
    willSendResponse(o) {
        const { context, graphqlResponse } = o

        context.trackErrors(graphqlResponse.errors)

        return o
    }
}
```

Edit by @evans :
fixes #1343
fixes #614 as the request object can be taken from context or from requestDidStart
fixes #631 ""

* Remove context from extra extension functions

The context shouldn't be necessary for format, parse, validation, and
execute. Format generally outputs the state of the extension. Parse and
validate don't depend on the context. Execution includes the context
argument as contextValue

* Move change entry under vNext
@rnenjoy
Copy link

rnenjoy commented Nov 16, 2020

Needs this aswell.

@macsj200
Copy link

@martijnwalraven An example use case for this is if you have a custom logger object that you attach to the context, you may want to be able to reference that logger in the formatError() body.

@abernix
Copy link
Member

abernix commented Mar 5, 2021

For anyone encountering this issue still, the formatError on Apollo Server today is a hoisting of the principle/pattern behind the underlying formatError in graphql-js, which doesn't have a notion of context supplied to it. For those needing to react to things on the context (which makes a lot of sense!), you might consider using the plugins API's didEncounterErrors or willSendResponse life-cycle hooks, both of which receive context. And for the custom logger use-case above, they also receive the logger that is passed into the ApolloServer constructor, if you've provided one (but that defaults to console, if you haven't).

@Kl4rity
Copy link

Kl4rity commented Aug 31, 2021

Unfortunately, this doesn't allow you to catch exceptions that are thrown in the early stages of processing request, such as parsingDidStart or validationDidStart. Meaning, that any errors thrown in preprocessing the request (say, adding a user-object to the request) cannot be handled by didEncounterErrors or willSendResponse. :(

@glasser
Copy link
Member

glasser commented Aug 31, 2021

@Kl4rity this is discussed with some workaround ideas at #3039 (comment)

@Uzziel306
Copy link

Everyone i got a solution! 🎉
it's true that you will not get the context in this formatError function, but you could use the formatResponse function, You can catch the all error in the response, and you'll have the context as well. Good luck! 🪨

@apollographql apollographql locked and limited conversation to collaborators Mar 22, 2022
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 a pull request may close this issue.