1165304 - ping["application"]["channel"] != ping["environment"]["settings"]["update"]["channel”]

Status: RESOLVED FIXED

(Toolkit :: Telemetry, defect)

Description

[Roberto Agostino Vitillo (:rvitillo)]

I have seen a recent v4 ping in which the ping["application"]["channel"] and ping["environment"]["settings"]["update"]["channel”] differ. 

Is that expected?

Comment 1

[Benjamin Smedberg]

What are the values? Note that there is a difference between the default (compiled-in) update channel (from nsIXULRuntime) and the actual channel, for RCs on the beta channel. And there may be differences in how we report partner-build channel modifications as well.

Comment 2

[Georg Fritzsche [:gfritzsche]]

That is odd.

They should report the same value:
https://hg.mozilla.org/mozilla-central/annotate/35918b0441b4/toolkit/components/telemetry/TelemetryEnvironment.jsm#l868
https://hg.mozilla.org/mozilla-central/annotate/35918b0441b4/toolkit/components/telemetry/TelemetryEnvironment.jsm#l880

... vs.:
https://hg.mozilla.org/mozilla-central/annotate/35918b0441b4/toolkit/components/telemetry/TelemetryController.jsm#l447
https://hg.mozilla.org/mozilla-central/annotate/35918b0441b4/toolkit/components/telemetry/TelemetryController.jsm#l460

The values are collected at different times though. The reported values would indeed be interesting for further clues.

Comment 3

[Roberto Agostino Vitillo (:rvitillo)]

The values are nightly and release for ping["application"]["channel"] and ping["environment"]["settings"]["update"]["channel”] respectively.

Comment 4

[Georg Fritzsche [:gfritzsche]]

Ok, that sounds like someone is testing things - i can't imagine other reasons really why a browser would have those two values at different times.

Comment 5

[Georg Fritzsche [:gfritzsche]]

I'm monitoring this for a bit:
https://pipeline-prototype-cep.prod.mozaws.net/#plugins/filters/PrototypeSandbox-gfritzsche_ChannelDiffers

I will close this out if nothing unexpected shows up there.

Comment 6

[Alessio Placitelli [:Dexter]]

I had a look at this issue and run a couple of tests:

1) With a test profile, ran 39 beta and got the correct channels (environment.settings.update.channel and application.channel are the same, "beta"). Then I opened Nightly with the same profile and the channels behaved as expected ("nightly").
2) With a different test profile, ran Nightly and let Telemetry init.  Then I change the app.update.channel default (UpdateChannel.get reads the *DEFAULT* value for that pref) using |Services.prefs.getDefaultBranch(null).setCharPref("app.update.channel", "release");|

With the second test, I get what we see in the monitor (in my case, application.channel as release and environment.settings.update.channel as nightly).

That explains the nightly/release channel difference with a manual testing, since we shouldn't even be receiving pings with a "release" channel right now.

The aurora-cck-opensuse/aurora channel difference is due to partner repacking [1]: since "aurora-cck-opensuse" will still be treated as "aurora", we should exclude the partner info from the channel entry. We have the partner info in a separate section in the ping anyway (thanks Georg and Standard8 ;-) ).

[1] - https://hg.mozilla.org/mozilla-central/annotate/2c815cc65cc9/toolkit/modules/UpdateChannel.jsm#l34

Comment 7

[Alessio Placitelli [:Dexter]]

Attachment: bug1165304.patch

Comment 8

[Alessio Placitelli [:Dexter]]

Try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=ebeee6ed18f8 (also covers bug 1168931)

Comment 9

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/b8766738a9ba

Comment 10

[Ryan VanderMeulen [:RyanVM]]

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

Comment 11

[Georg Fritzsche [:gfritzsche]]

Side-note, it looks like someone is actually currently testing channel switching:
https://ask.mozilla.org/question/1572/restart-selfother-firefox-instance-with-restore-session-but-other-build/

Comment 12

[Georg Fritzsche [:gfritzsche]]

Comment on attachment 8612192 [details] [diff] [review]
bug1165304.patch

Approval Request Comment
[Feature/regressing bug #]:
Unified Telemetry, https://wiki.mozilla.org/Unified_Telemetry
This is part of the first (main) batch of uplifts to 40 to enable shipping on that train, see bug 1120356, comment 2.
[User impact if declined]:
Data & measurement insight projects delayed or blocked with direct impact on projects depending on this.
[Describe test coverage new/current, TreeHerder]:
We have good automation coverage of the feature.
We also had manual tests of the main tasks as well as confirmation of correct behavior on Nightly for the patches here.
[Risks and why]:
Low-risk - these patches are rather isolated to Telemetry and have been on Nightly for a while with no bad reports.
We intend to track on-going data quality and other issues during the 40 aurora & beta and flip the new behavior off when it doesn't meet the requirements.
[String/UUID change made/needed]:
The only string changes were to the about:telemetry page.
We decided that we can live with missing translations on that page for a cycle as that page is not exactly user-facing.

Comment 13

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8612192 [details] [diff] [review]
bug1165304.patch

part of the unified telemetry uplift, taking it

Comment 14

[Georg Fritzsche [:gfritzsche]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/cbb2aac0a8e5