Closed Bug 1920562 Opened 2 months ago Closed 1 month ago

Remove setEventRecordingEnabled, leaving all Legacy Telemetry events as default-on

Categories

(Toolkit :: Telemetry, task, P1)

task

Tracking

()

RESOLVED FIXED
133 Branch
Tracking Status
firefox133 --- fixed

People

(Reporter: chutten, Assigned: chutten)

References

(Regressed 1 open bug)

Details

Attachments

(5 files)

Legacy Telemetry's setEventRecordingEnabled API has long been more of an annoyance than a help. (In fact, I've used it as justification to use Glean instead). It was intended to supply event instrumentors with confidence to control when and how often their events would be recorded and express our continued preference for default-off instrumentation.

At time of writing, no one uses it that way, preferring to enable event recording in code immediately preceding the recording of the events.

(Okay, so TRRService ties theirs to a pref which could be changed, but it isn't changed by code or experiment. Others could have depended on squelching events that are recorded earlier than the category being enabled, but we haven't found any that do.)

Since we're looking at deprecating and removing other Legacy Telemetry event APIs in favour of Glean (whose events, it must be said, supply a superior operational safety guarantee through Server Knobs which some folks have actually used to ship instrumentation defaulted to off), it's a good time to remove this unused and ill-understood mechanism.

This bug is about:

  • Removing the setEventRecordingEnabled API and all of its uses
  • Defaulting all events to enabled
  • Documenting in the Legacy Telemetry event docs any risks now borne by instrumentors because of this API's removal
    • Instruct users looking for this functionality after this removal to build their own e.g. out of prefs.
Pushed by chutten@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/62ab18879eea Switch all legacy events to default to enabled r=florian,janerik,devtools-reviewers,nchevobbe https://hg.mozilla.org/integration/autoland/rev/cd3672fc08ed Remove C++ Telemetry::SetEventRecordingEnabled r=florian,necko-reviewers,valentin https://hg.mozilla.org/integration/autoland/rev/a68fd13a33ae Remove JS uses of Services.telemetry.setEventRecordingEnabled r=florian,settings-reviewers,pip-reviewers,credential-management-reviewers,search-reviewers,devtools-reviewers,sync-reviewers,sessionstore-reviewers,omc-reviewers,migration-reviewers,firefox-desktop-core-reviewers ,urlbar-reviewers,sfoster,nchevobbe,valentin,Gijs,dimi,lina,mconley,pdahiya https://hg.mozilla.org/integration/autoland/rev/4405387ae770 Remove Services.telemetry.setEventRecordingEnabled r=florian,janerik https://hg.mozilla.org/integration/autoland/rev/8f085ab589a8 Remove TelemetryEvents.init r=florian

...what? Okay, uh... I don't know how that could happen. And it doesn't reproduce locally. Maybe a faulty merge? Lemme pop it onto try again real quick.

Flags: needinfo?(chutten)

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

...what? Okay, uh... I don't know how that could happen.

Bug 1822083 seems vaguely related. But no obvious solution there.

try can reproduce it, but I can't. And the mystery is deepened by how it's a d3d11 pref failing tests on Linux. There's precious little code that even references the pref at all, and the manipulation causing the failure is a clearUserPref call from somewhere in JS.

The stack does do some pref work, removing network.trr.confirmation_telemetry_enabled, security.certerrors.recordEventTelemetry, and security.protectionspopup.recordEventTelemetry. None even close to layers.d3d11.*. There are no changes to gfx/**/* in the patches.

I'm at a loss. I'm going to try binary searching the patch stack to identify which patch triggers the failure and then I'll subdivide the change to try and narrow it down further, roundtripping through try each time.

Reverting the top three patches (removing TelemetryEvents.init, Services.telemetry.setEventRecordingEnabled, and removing all JS calls to Services.telemetry.setEventRecordingEnabled) still results in the pref test failing, however reverting the fourth patch (removing the C++ uses of SetEventRecordingEnabled and the API) gives a clean run.

Which would suggest that it's something in this patch that's causing the test to fail.

On a hunch, I added back in the definition for the network.tss.confirmation_telemetry_enabled pref to StaticPrefList.yaml and the test now passes. So let's get this landed again.

Pushed by chutten@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/d40aabb6a4f4 Switch all legacy events to default to enabled r=florian,janerik,devtools-reviewers,nchevobbe https://hg.mozilla.org/integration/autoland/rev/a39cdf7de3a6 Remove C++ Telemetry::SetEventRecordingEnabled r=florian,necko-reviewers,valentin https://hg.mozilla.org/integration/autoland/rev/d56bf9374416 Remove JS uses of Services.telemetry.setEventRecordingEnabled r=florian,extension-reviewers,settings-reviewers,pip-reviewers,credential-management-reviewers,search-reviewers,devtools-reviewers,sync-reviewers,sessionstore-reviewers,omc-reviewers,migration-reviewers,firefox-desktop-core-reviewers ,urlbar-reviewers,sfoster,nchevobbe,valentin,Gijs,dimi,lina,mconley,pdahiya,willdurand https://hg.mozilla.org/integration/autoland/rev/96f22ea62b03 Remove Services.telemetry.setEventRecordingEnabled r=florian,janerik https://hg.mozilla.org/integration/autoland/rev/595eef978917 Remove TelemetryEvents.init r=florian
Regressions: 1923539
Blocks: 1923953
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: