Closed Bug 1726444 Opened 1 year ago Closed 7 months ago

TB tries to ping telemetry even if set offline

Categories

(Toolkit :: Telemetry, defect, P3)

x86_64
Windows 10
defect

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: buecher, Unassigned, NeedInfo)

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

Status: NEW → UNCONFIRMED
Component: Untriaged → General
Ever confirmed: false
Flags: needinfo?(mkmelin+mozilla)

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

Flags: needinfo?(mkmelin+mozilla)

klaus ...

Can you reproduce with Firefox?
Probably a Services.io.offline check should be added somewhere

Flags: needinfo?(buecher)
Whiteboard: [closeme 2021-09-25]
Blocks: tb91found

klaus?

No longer blocks: tb91found
Component: General → Telemetry
Product: Thunderbird → Toolkit
Version: Thunderbird 91 → unspecified

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.

Severity: -- → S4
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3

Resolved per whiteboard

Status: NEW → RESOLVED
Closed: 7 months ago
Resolution: --- → INCOMPLETE
Whiteboard: [closeme 2021-09-25]
You need to log in before you can comment on or make changes to this bug.