-
Notifications
You must be signed in to change notification settings - Fork 273
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add logs and extend metrics for
graphql_validation_mode: both
(#3674)
This adds logging for query validation errors with either Rust or JS when there is a mismatch, i.e. one of them validates but the other does not. In other cases we are not really interested in the specific error (it will just go back to the user), so we don't need to log there. To log the Rust validation error well, I now store the ApolloDiagnostics that were produced on `Query{}`. `Query` is serializable for caching, but ApolloDiagnostic is not. Here I just skipped serializing `ApolloDiagnostic` so if `Query` is loaded from cache, it does not have the validation error stored. I'm not sure this is the right thing to do. The ApolloDiagnostics are later used after query planning (which may produce a JS validation error). So it's correct if we can ~safely assume that we only have valid Query instances cached. Otherwise we might get spurious error logs from this. - [ ] So is that a safe assumption? Reading the CachingQueryPlanner implementation I think it does only store errors (then it's not a `Query` instance) and fully successful planning (then it has run both Rust and JS validation already). So it looks fine, but it could be a bit brittle to rely on this. I also simplified the validation error printing which - [x] depends on apollographql/apollo-rs#630. - [x] and on #3675 <!-- start metadata --> **Checklist** Complete the checklist (and note appropriate exceptions) before a final PR is raised. - [ ] Changes are compatible[^1] - [ ] Documentation[^2] completed - [ ] Performance impact assessed and acceptable - Tests added and passing[^3] - [ ] Unit Tests - [ ] Integration Tests - [ ] Manual Tests **Exceptions** *Note any exceptions here* **Notes** [^1]. It may be appropriate to bring upcoming changes to the attention of other (impacted) groups. Please endeavour to do this before seeking PR approval. The mechanism for doing this will vary considerably, so use your judgement as to how and when to do this. [^2]. Configuration is an important part of many changes. Where applicable please try to document configuration examples. [^3]. Tick whichever testing boxes are applicable. If you are adding Manual Tests: - please document the manual testing (extensively) in the Exceptions. - please raise a separate issue to automate the test and label it (or ask for it to be labeled) as `manual test`
- Loading branch information
1 parent
2915737
commit 81fc803
Showing
4 changed files
with
86 additions
and
65 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
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