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

Add didEncounterErrors to request pipeline API. #2719

Merged

Conversation

abernix
Copy link
Member

@abernix abernix commented May 24, 2019

(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 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.

(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.
@abernix abernix merged commit 8587e4d into release-2.6.0 May 24, 2019
@abernix abernix deleted the abernix/requestPipelineAPI-didEncounterErrors branch May 24, 2019 21:06
abernix added a commit that referenced this pull request May 24, 2019
abernix added a commit that referenced this pull request May 27, 2019
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.
abernix added a commit that referenced this pull request May 27, 2019
abernix added a commit that referenced this pull request May 27, 2019
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.
abernix added a commit that referenced this pull request May 27, 2019
@abernix abernix added this to the Release 2.6.0 milestone May 27, 2019
@abernix abernix mentioned this pull request Jun 30, 2019
4 tasks
abernix added a commit that referenced this pull request Jun 30, 2019
@lorensr
Copy link
Contributor

lorensr commented Aug 18, 2019

@abernix
Copy link
Member Author

abernix commented Aug 20, 2019

And just to clarify document is the DocumentNode, and operation is the OperationDefinitionNode, though neither is guaranteed since the error might have happened during parsing and validation, or might have occurred even earlier in the pipeline. This will be included in the documentation soon!

StephenBarlow pushed a commit that referenced this pull request Aug 23, 2019
StephenBarlow pushed a commit that referenced this pull request Aug 28, 2019
StephenBarlow pushed a commit that referenced this pull request Sep 13, 2019
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 22, 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.

2 participants