TB tries to ping telemetry even if set offline
Categories
(Toolkit :: Telemetry, defect, P3)
Tracking
()
People
(Reporter: buecher, Unassigned)
Details
TB 91 is set to offline.
In error console, I see multiple unsuccessfull attempts of telemetry to ping somewhere.
Not knowing what telemetry tries to do there, that still feels counter-intuitive if TB is set to offline.
Klaus
|
||
Comment 1•3 years ago
|
||
ref bug 800321
|
||
Comment 2•3 years ago
|
||
I don't think Thunderbird per se it responsible for the sending. It's all in (shared code) at https://searchfox.org/mozilla-central/source/toolkit/components/telemetry/app/TelemetrySend.jsm
Can you reproduce with Firefox?
Probably a Services.io.offline check should be added somewhere
|
|
||
Comment 3•3 years ago
|
||
klaus ...
Can you reproduce with Firefox?
Probably aServices.io.offlinecheck should be added somewhere
|
|
||
Updated•3 years ago
|
|
|
||
Updated•3 years ago
|
|
||
Comment 5•3 years ago
|
||
The best place for this sort of check looks like it would be sendingEnabled... but it looks like if we put it there, then we will never retry sending that ping and simply archive it for all time.
Next most likely looks like the property canSendNow... however, it appears to be most interested in describing whether Firefox is physically able to send now and will happily ask pingsender to try... which I gather isn't the desired outcome.
Next from there is to interject ourselves in submitPing. As new pings come by and try to be sent we can decide to save them as pending pings (so they'll be retried later) and then bail out in much the way that canSendNow presently works. We'll just have to do that earlier than the pingsender check (but below the sendingEnabled check. If we're both offline and the user's disabled the Telemetry pref, we still want to drop the ping on the floor after all.). It's not a quick stop, though, as any pending or current pings in the scheduler will remain there, and if the scheduler ticks (like after a timer due to throttling, or near local midnight) they'll try to be sent again. But persisting the current pings down to pending pings or pausing the tick would just be a pain. If we're that worried, a second check in _doSendTask or nearby will handle it... but that level of complexity is asking for bugs.
Yes, that seems most appropriate. Somewhere around here we could have an early return and a nice comment. And a nice test or four in toolkit/components/telemetry/tests/unit possibly in test_TelemetrySend.js.
Resolved per whiteboard
this is still happening in 115. It is totally annoying when developing, because suddenly error console is flooded by red telemetry error messages, happening often
Description
•