Figure out a glean migration strategy for the media.video_hardware_decoding_support and media.video_hd_hardware_decoding_support boolean scalars
Categories
(Toolkit :: Telemetry, task, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox133 | --- | fixed |
People
(Reporter: florian, Assigned: chutten)
References
Details
Attachments
(3 files)
These 2 scalars are the only boolean scalars that seem intentionally recorded outside the parent process. This is annoying to migrate them to Glean as the Boolean metric type in Glean is only supported on the parent process.
Possible strategies:
- change Glean to support this (unfortunate as it looks like these 2 probes would be the only consumer)
- check if the probe is really useful, and if not remove it.
- change the code to IPC the value to the parent, and always record on the parent.
These probes landed in bug 1733722 and bug 1741286.
Alastor, Chris, opinions on the best path forward?
Assignee | ||
Comment 1•1 month ago
|
||
Some background for those coming at this fresh: FOG specifically didn't implement non-commutative metric operations over IPC because it couldn't guarantee order. If, for example, two child processes A and B both set
a value for a boolean
metric but disagree on the value: how can FOG ensure that it gets the "correct" one?
This approach is in line with Glean's philosophy of being opinionated about design in ways that result in predictable and consistent data quality. But it misses the "unsafety valve" that characterizes how we express those opinions in code: e.g. yes, we're going to ask you to let us do timing for you because we can guarantee things about the timing sources we have access to within the SDK, but we'll also give you a raw API if you feel you can provide the same guarantees or educate your consumers about the differences.
All this is to say that it's not merely a choice of "do we augment FOG to support IPC for exactly two boolean
metrics", this is a "do we commit to supplying an unsafety valve for all non-commutative metric operations". We have space in our philosophy for it now, so maybe it's time. But if we don't need it because the probe isn't used or useful, then maybe this decision can wait for another day.
Comment 2•1 month ago
|
||
(In reply to Florian Quèze [:florian] from comment #0)
- change the code to IPC the value to the parent, and always record on the parent.
We should do this way, as those probes are still helpful for us to monitor the hardware decoding status, eg. [1]
[1]
https://sql.telemetry.mozilla.org/queries/82362/source#204048
https://sql.telemetry.mozilla.org/queries/82391/source#204112
Assignee | ||
Comment 3•29 days ago
|
||
Sounds like we need to permit non-commutative operations for a minimum of boolean
(and, thus, labeled_boolean
) metrics. I'll write a quick design proposal.
Assignee | ||
Comment 4•29 days ago
|
||
ni?janerik as Glean End-to-end lead for sign-off.
I don't expect this to be controversial. I just know that it's easier to change words than an implemented system currently in use. (So get your feedback in now when it's cheap to change)
Assignee | ||
Comment 6•23 days ago
|
||
Assignee | ||
Comment 7•23 days ago
|
||
https://hg.mozilla.org/mozilla-central/rev/32783242e758
https://hg.mozilla.org/mozilla-central/rev/47d997a65266
Description
•