-
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
Add didEncounterErrors
to request pipeline API.
#2719
Add didEncounterErrors
to request pipeline API.
#2719
Conversation
(As I mentioned at the bottom of #2714) This adds a new life-cycle event to the new request pipeline API called `didEncounterErrors`, which receives `requestContext`'s **unformatted** `errors`. (The `requestContext` represents an individual request within Apollo Server.) These `errors` give access to potentially different `errors` than those received within `response.errors`, which are sent to the client and available on the `willSendResponse` life-cycle hook, since they are **not** passed through the `formatError` transformation. This can allow plugin implementers to take advantage of the actual errors and properties which may be pruned from the error before transmission to the client. While most other request pipeline life-cycle events provide a guarantee of their arguments, this `didEncounterErrors` will have a little bit less certainty since the errors could have happened in parsing, validation, or execution, and thus different contracts would have been made (e.g. we may not have been able to negotiate a `requestContext.document` if we could not parse the operation). This still needs tests and I suspect I'll have some additional changes prior to this becoming official, but it can ship as-is for now and will live in the Apollo Server 2.6.0 alpha for the time-being. Use with minimal risk, but with the caveat that the final API may change. Also, I'll need to add docs to #2008.
This accounts for some preliminary tests for things which don't already have tests, but was primarily motivated by the new `didEncounterErrors` life-cycle hooks that I introduced in #2719.
This accounts for some preliminary tests for things which don't already have tests, but was primarily motivated by the new `didEncounterErrors` life-cycle hooks that I introduced in #2719.
For anyone looking for more info on which includes:
|
And just to clarify |
(As I mentioned at the bottom of #2714)
This adds a new life-cycle event to the new request pipeline API called
didEncounterErrors
, which receivesrequestContext
's unformattederrors
. (TherequestContext
represents an individual request within Apollo Server.) Theseerrors
give access to potentially differenterrors
than those received withinresponse.errors
, which are sent to the client and available on thewillSendResponse
life-cycle hook, since they are not passed through theformatError
transformation. This can allow plugin implementers to take advantage of the actual errors and properties which may be pruned from the error before transmission to the client.While most other request pipeline life-cycle events provide a guarantee of their arguments, this
didEncounterErrors
will have a little bit less certainty since the errors could have happened in parsing, validation, or execution, and thus different contracts would have been made (e.g. we may not have been able to negotiate arequestContext.document
if we could not parse the operation).This should hopefully be a step in the right direction for desires like those expressed in #1709, and helps make that more of a reality when combined with the recent #2714.
This still needs tests and(Edit: Tests are now included in 705defb) I suspect I'll have some additional changes prior to this becoming official, but it can ship as-is for now and will live in the Apollo Server 2.6.0 alpha for the time-being. Use with minimal risk, but with the caveat that the final API may change. Also, I'll need to add docs to #2008 before we finally ship this.