Consolidate the ping upload check logic

NEW
Unassigned

Status

()

Toolkit
Telemetry
P3
normal
7 months ago
7 months ago

People

(Reporter: Dexter, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(firefox55 affected)

Details

(Whiteboard: [measurement:client])

(Reporter)

Description

7 months ago
As found in bug 1341349, we might need to check if we're allowed to send pings in places other than TelemetrySend.jsm.

We should consolidate and expose a single API from TelemetrySend to check if we're good to send pings.

(In reply to Georg Fritzsche [:gfritzsche] from bug 1341349 comment #5)
> 
> Concerns:
> (1) don't send data before the privacy policy was accepted
> (1a) start sending data once the privacy policy was accepted
> (2) don't send data from non-official builds etc.
> (3) handle data upload pref switches
> (3a) stop sending when data upload is disabled
> (3b) start sending again when data upload is enabled
> 
> (1) & (2) can be addressed using e.g. TelemetrySends canSendNow() &
> sendingEnabled().
> (1a) needs a TelemetryReportingPolicy listener.
> (3) needs upload pref listeners.
> 
> ...
>
> I agree that we should consolidate the upload check logic, not duplicate it
> (whether in TelemetrySend, TelemetryController, ...).
> Quickly checking around, the different pieces of the logic are still a
> bit... distributed and could be centralized.
> In the end this is one state machine (with different actions on state
> transitions etc.).
(Reporter)

Updated

7 months ago
Priority: -- → P3
Whiteboard: [measurement:client]
I've been looking into this in the context of bug 1341349 and I still believe we need to expose at least two methods for this: if TelemetrySend.sendingEnabled() returns false then not only the ping is not sent, but it's not persisted either; if TelemetrySend.canSendNow() returns false on the other hand the ping is not sent but it's persisted to disk.
You need to log in before you can comment on or make changes to this bug.