Closed Bug 1165304 Opened 8 years ago Closed 7 years ago
ping["application"]["channel"] != ping["environment"]["settings"]["update"]["channel”]
I have seen a recent v4 ping in which the ping["application"]["channel"] and ping["environment"]["settings"]["update"]["channel”] differ. Is that expected?
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.
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.
The values are nightly and release for ping["application"]["channel"] and ping["environment"]["settings"]["update"]["channel”] respectively.
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.
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.
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 : 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 ;-) ).  - https://hg.mozilla.org/mozilla-central/annotate/2c815cc65cc9/toolkit/modules/UpdateChannel.jsm#l34
Assignee: nobody → alessio.placitelli
Status: NEW → ASSIGNED
Attachment #8612192 - Flags: review?(gfritzsche)
Attachment #8612192 - Flags: review?(gfritzsche) → review+
Try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=ebeee6ed18f8 (also covers bug 1168931)
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 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.
Attachment #8612192 - Flags: approval-mozilla-aurora?
Comment on attachment 8612192 [details] [diff] [review] bug1165304.patch part of the unified telemetry uplift, taking it
Attachment #8612192 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.