1600249 - Retry sending deletion request ping

Status: RESOLVED FIXED

(Data Platform and Tools :: Glean: SDK, defect, P1)

Description

[Jan-Erik Rediger [:janerik]]

On desktop, Telemetry will retry to send the deletion request ping, even if upload is otherwise disabled.

Glean will not do that.
Is that a requirement?
If so, we could launch an upload task on start to check if any left-over deletion_request pings are around.

Comment 1

[Chris H-C :chutten]

I'm not sure what we need from a compliance POV. +Alicia for a ruling on that.

I ended up having the Desktop impl retry on failure because it was simple to do. My vote is to, even if we don't have to for compliance, spend at least enough effort to figure out how hard it would be to do in the Glean SDK. If it ends up being a small lift, let's do it.

Comment 2

[Alicia Gray]

(In reply to Chris H-C :chutten from comment #1)

I'm not sure what we need from a compliance POV. +Alicia for a ruling on that.

I ended up having the Desktop impl retry on failure because it was simple to do. My vote is to, even if we don't have to for compliance, spend at least enough effort to figure out how hard it would be to do in the Glean SDK. If it ends up being a small lift, let's do it.

Yes, as a user I would expect that if I opted out of telemetry to enable the data deletion and there was a failed attempt that we would try again to send the ping unless we have some kind of fatal error. I think from a regulatory perspective that would also be the expectation since we are telling users that opt-out will trigger the relevant deletion.

Comment 3

[Jan-Erik Rediger [:janerik]]

Attachment: GitHub Pull Request

Comment 4

[Jan-Erik Rediger [:janerik]]

Looks like it currently already retries: https://github.com/mozilla/glean/blob/master/glean-core/android/src/main/java/mozilla/telemetry/glean/scheduler/DeletionPingUploadWorker.kt#L188

As I understand it it's tried for a total runtime of 10 minutes (unless force-stopped I guess). Just makes it a bit harder to test.