-
Notifications
You must be signed in to change notification settings - Fork 2k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Invoke
didEncounterErrors
for known errors during pre-parse. (#3614)
* tests: Assert `didEncounterErrors` is invoked for execution errors. Previously a missing test. * tests: Assert error conditions for existing APQ logic (prior to improvements). Previously, a number of APQ errors did not have tests for errors which could arise at runtime. These include: - When the APQ `version` is not a version that we support. (Currently, the only supported `version` is `1`. - When the APQ `version` is entirely omitted. (It must be `1`.) - When the provided APQ `sha256Hash` doesn't match the provided `query` during APQ registration. I'm adding these tests which assert the existing logic without making any changes to the logic itself prior to making a number of changes to said logic which will ensure that these (again, existing) errors are _also_ propagated to the `didEncounterErrors` hook (They currently are NOT!). * Invoke `didEncounterErrors` for errors during pre-parse phases. Roughly, these "pre-parse" errors come in two forms: When the query was entirely omitted, or APQ (automated persisted query) errors. Arguably, there is a third form of pre-parse errors, but it would be unexpected and potentially out of scope of the `didEncounterErrors` life-cycle hook. Such an error would still be caught by `runHttpQuery.ts`, but we wouldn't have a guarantee that our plugins have been initialized. This is unlikely to improve until we re-work the entirety of the request pipeline in Apollo Server 3.x. While these errors were in-fact causing errors at runtime that were being delivered to the client, those errors were not being delivered to the plugin's `didEncounterErrors` hooks, causing reduced visibility by reporting tools which utilize that life-cycle hook. This commit changes the parent class of `InvaidGraphQLRequestError` from `Error` to `GraphQLError` in order to allow such an error to be received by `didEncounterErrors`, which requires `GraphQLError`s. The `GraphQLError` itself is still an `instanceof Error`, so any existing code that leverages such a condition should still work as expected, and I suspect that most other conditions that could be checked on either an `Error` or `GraphQLError` should also still remain the same. Despite any uncertain here, I'd call this a net-win for reporting errors more reliably to the hook on which they're expected to be received. * Add CHANGELOG.md for #3614.
- Loading branch information
Showing
5 changed files
with
252 additions
and
32 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.