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

RESOLVED FIXED in Firefox 40

Status

()

Toolkit
Telemetry
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: rvitillo, Assigned: Dexter)

Tracking

Trunk
mozilla41
Points:
---

Firefox Tracking Flags

(firefox40 fixed, firefox41 fixed)

Details

(Whiteboard: [uplift])

Attachments

(1 attachment)

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

Is that expected?
(Reporter)

Updated

3 years ago
Flags: needinfo?(gfritzsche)
Blocks: 1154224

Comment 1

3 years ago
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.
Flags: needinfo?(rvitillo)
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.
Flags: needinfo?(gfritzsche)
(Reporter)

Comment 3

3 years ago
The values are nightly and release for ping["application"]["channel"] and ping["environment"]["settings"]["update"]["channel”] respectively.
Flags: needinfo?(rvitillo)
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.
(Assignee)

Comment 6

3 years ago
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
(Assignee)

Comment 7

3 years ago
Created attachment 8612192 [details] [diff] [review]
bug1165304.patch
Assignee: nobody → alessio.placitelli
Status: NEW → ASSIGNED
Attachment #8612192 - Flags: review?(gfritzsche)
Attachment #8612192 - Flags: review?(gfritzsche) → review+
(Assignee)

Comment 8

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

Comment 9

3 years ago
https://hg.mozilla.org/integration/fx-team/rev/b8766738a9ba
https://hg.mozilla.org/mozilla-central/rev/b8766738a9ba
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
status-firefox41: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
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/
status-firefox40: --- → affected
Whiteboard: [uplift]
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+
https://hg.mozilla.org/releases/mozilla-aurora/rev/cbb2aac0a8e5
status-firefox40: affected → fixed
You need to log in before you can comment on or make changes to this bug.