Detect when telemetry has been disabled to inform Glean
Categories
(Conduit :: moz-phab, defect)
Tracking
(Not tracked)
People
(Reporter: janerik, Unassigned)
Details
(Keywords: conduit-triaged)
Right now moz-phab calls Glean.initialize always with upload_enabled=True (code).
This is mostly fine as it's only triggered when the user has data collection enabled.
However one thing we're missing that way are deletion-request pings.
These are automatically sent by Glean when a user has upload disabled and is a signal to our pipeline to remove the client's data (as identified by their client id).
That also cycles the local client id, so the next time upload gets enabled the client selects a new random client id.
Glean ensures it only triggers such a deletion-request ping once. If upload is disabled Glean will also not store any data and any metric recording calls will become essentially a no-op.
You should consider always calling Glean.initialize with the correct preference.
Initially moz-phab worked that way; however after a long run of stability and performances issues we now only lazily initialise Glean.
Rather than regressing on that, we could detect if the telemetry preference has changed and perform a one-time call to Glean to trigger the deletion-request ping.
|
Reporter | |
Comment 2•3 years ago
|
||
Lazily initializing is not even the problem.
I'm curious about the stability/performance issues you mentioned though. We do care about this in the Glean SDK and if we know about it we can try to address it. Apart from the deletion-request ping an initialized Glean should be essentially a no-op, so we'd hope that additional wrapping in the application might be unnecessary that way.
Glean already tracks enough state to know when the upload-enabled is flipped. While tracking this in the application itself is possible, it should not be the application's task.
The deletion-request ping is important for our pipeline to work correctly and act according to user requests.
Description
•