apollographql
Change usage reporting defaults backwards-incompatibly to send less data
In order to make usage reporting have better performance and less potential PII leakage by default, we should change the default usage reporting to send even less information by default. We previously changed usage reporting to make variable and HTTP header reporting opt-in. We should continue down this path to make sending error bodies in traces opt-in (though we should still probably track the number of errors by default). Furthermore, now that the Unified Reporting and referenced field usage projects are done, we can change the defaults to make traces be an opt-in feature (which gives you access to traces on the Operations page, field execution counts on the Fields page, and field latencies in Explorer and VSCode timing hints) that isn’t on by default. This would mean that by default we would only send summarized statistics of operations, not any data about individual requests, and the only user-provided strings would be operation signatures (with literals removed as always).
Hmm. If errors are masked, should we override the logic in defaultSendOperationAsTrace that treats traces with errors specially?
Hmm. If errors are masked, should we override the logic in defaultSendOperationAsTrace that treats traces with errors specially?
We can make this change at any time without compat worries because that heuristic is deliberately unspecified.
In the interest of moving this project towards finished, let's leave the defaults for "send any traces?" and "instrument fields?" at turned on. The onboarding experience is better that way (ie, no changes needed to Studio UI) and if it's a performance problem you can tweak the settings (or move to Router if you're on Gateway!).
That said:
Right now there isn’t an easy clearly supported way to say “I just don’t want to send traces at all”. There’s experimental_sendOperationAsTrace which is, well, experimental (and completely replaces the main trace vs stats heuristic). And there’s fieldLevelInstrumentation: false which sort of does that but it will still send traces with (masked) errors for parse and validation failures. So while I’m not going to change the default behavior, I am going to add a little sendTraces: false setting that you can do to turn off sending anything as a trace (but it doesn’t imply fieldLevelInstrumentation: false! you can still get field execution stats from this!)