1573868 - Upload Mobile Activation Ping in onStart

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect, P1)

Description

[Vlad Baicu]

Bug 1534451 added a non-trivial amount of background
computation during onCreate. This introduced regressions by tickling the balance of existing race conditions.

We're changing this by now uploading in onStart. Ideally we want to send this mobile activation ping at least once from every client at startup.

Comment 1

[Vlad Baicu]

Attachment: Bug 1573868 - Upload Mobile activation ping in onStart. r=nalexander

Bug 1534451 added a non-trivial amount of background computation during
onCreate. This introduced regressions by tickling the balance of existing
race conditions.

We're changing this by now uploading in onStart. Ideally we want to send
this mobile activation ping at least once from every client at startup. This change
should have minimal impact and keep the same consistency with the core ping.

Comment 2

[Chris Peterson [:cpeterson]]

status-firefox-esr68=affected because we'll want to uplift this fix to Fennec ESR 68.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d1e08b5e6584
Upload Mobile activation ping in onStart. r=nalexander

Comment 4

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/d1e08b5e6584

Comment 5

[Chris Peterson [:cpeterson]]

Vlad, can you please request uplift for your fix to Fennec ESR 68.1 and Beta?

Comment 6

[Vlad Baicu]

Comment on attachment 9085483 [details]
Bug 1573868 - Upload Mobile activation ping in onStart. r=nalexander

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration:
• User impact if declined: Bug 1534451 introduced a system addons regression. With this patch we aim to fix that issue.
• Fix Landed on Version:
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): We're delaying a bit the point at which we try to upload the activation ping in order to not interfere with other existing race conditions.
• String or UUID changes made by this patch:

Beta/Release Uplift Approval Request

• User impact if declined: Bug 1534451 introduced a system addons regression. With this patch we aim to fix that issue.
• Is this code covered by automated tests?: Unknown
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): We're delaying a bit the point at which we try to upload the activation ping in order to not interfere with other existing race conditions.
• String changes made/needed:

Comment 7

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9085483 [details]
Bug 1573868 - Upload Mobile activation ping in onStart. r=nalexander

Approved for Fennec 68.1b8.

Comment 8

[Razvan Maries]

https://hg.mozilla.org/releases/mozilla-beta/rev/1f7f411b0b5a

Comment 9

[Sebastian Hengst [:aryx] (needinfo on intermittent or backout)]

https://hg.mozilla.org/releases/mozilla-esr68/rev/71bdd4abde0d

Comment 10

[Frank Bertsch [:frank]]

Vlad, can you confirm what this change did?

I ran this comparison to the core ping: https://sql.telemetry.mozilla.org/queries/64358/source

And we're still seeing way more core pings and telemetry clients reporting core pings than activation.

Comment 11

[Frank Bertsch [:frank]]

A few questions on that analysis:

• What is the activation ping reporting as the channel? I see e.g. org.mozilla.firefox, and org.mozilla.firefox_beta (but no others). Are those release/beta?
• Did this change entail having every client send the activation ping at the beginning of every session? If so it doesn't look like it's even hit pre-release.
• Is this data being sent from nightly? What is the associated channel for that and ESR in the activation ping?

Comment 12

[Vlad Baicu]

Hello, we only delayed the point in time where the upload takes place in order to avoid race conditions when the app starts.

I think it's intended to see a lot more core pings because those have been in place for quite some time and they are sent per session. The activation ping is currently implemented to be sent once per client. Once we have a succesful upload of the activation ping, we will no longer upload on further attempts.

On channel we are reporting the android package name which should allow us to determine what distribution it is.

Yes, we should be uploading from nightly as well, try 'org.mozilla.fennec_aurora'. I don't think we have a way to differentiate between release and esr for any pings as of this moment but I can look more into it.

Comment 13

[Frank Bertsch [:frank]]

Okay, it doesn't sound like there's any good way to confirm this from the data. Let's assume that this bug's result is working as intended.

Comment 14

[Sorina Florean [:sflorean]]

Vlad, can you please provide the steps for verifying the fix? Thanks

Comment 15

[Sorina Florean [:sflorean]]

Diana has received the infos for testing. Removing the ni.

Comment 16

[Diana Rus]

Hi, I tried checking today the issue with https://sql.telemetry.mozilla.org/queries/63102/source#161803 but after running the query:
"select app_name, count(*) from moz-fx-data-shared-prod.mobile_live.activation_v1 where submission_timestamp > '2019-08-29' group by 1" there wasn't anything displayed.

As per my understanding a fresh install off the application or a clear data will trigger the activation ping.
I checked with a Sony Xperia Z5 (Android 7.0) on ESR Firefox Beta 68.1b8.

Comment 17

[Diana Rus]

Hi,
Verified as fixed, with the correct query, on Firefox Nightly 70.0a1(2019-08-29), Firefox Beta 70.0b2/Firefox Beta 69, ESR Firefox Beta 68.1b8 with:

• Sony Xperia Z5 (Android 7.0)
• Google Pixel 3 XL (Android 9)
• Samsung Galaxy Note 9 (Android 8.1.0)