-
Notifications
You must be signed in to change notification settings - Fork 272
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
use the operation signature as graphql.document in spans #2703
Conversation
This will prevent personal information (in hardcoded variables) from appearing in logs
@Geal, please consider creating a changeset entry in |
that'd be another good use case for modifying the original source in apollographql/apollo-rs#420 |
We could include the signature under a new |
Having |
We should also consider this option. |
with 91a3497 there's now an option. Note that the operation signature is still added in all cases: https://github.com/apollographql/router/blob/dev/apollo-router/src/plugins/telemetry/mod.rs#L323-L331 |
I think some bits need updating, the changelog is incorrect and we should add some docs. |
Is the signature we're referring to actually the "stats report key"? |
Yes that's the one |
We should not opaquely use the stats report key as the "graphql document" since it has a very Apollo-specific prefix on it. In the near term, if we want to use it to solve the stated goal, we should at the very least remove that (that is, the header part before and including the first |
Fix #2695
Fix #2820
This will prevent personal information (in hardcoded variables) from appearing in logs. A few points to address here:
Maybe here we could benefit from a router side solution instead of using the operation signature. Could we have a query transformation using apollo-compiler to remove indentation and hardcoded variables, but keep aliases and field order? @lrlna WDYT?
Checklist
Complete the checklist (and note appropriate exceptions) before a final PR is raised.
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