Allow runtime registration of new extra_keys for train-hopped New Tab events
Categories
(Toolkit :: Telemetry, enhancement, P3)
Tracking
()
People
(Reporter: ini, Unassigned)
References
(Blocks 1 open bug)
Details
In Bug 2075682, story impressions and clicks in the newtab-content ping were broken due to an incorrect train-hop version check when adding new extra_keys to existing telemetry events. Because Glean rejects the whole event when it contains an unknown extra key, version check shims (example) are necessary to prevent those keys from sending before the changes in metrics.yaml (which are not train-hoppable) make it to Release. However, this system relies on engineers remembering to include the shim and ensuring the correct Fx version, which is prone to error, and it also means changes to existing telemetry must wait to ride the trains.
Our runtime metrics registration for train-hop currently only diffs whole metrics and pings, so a new extra_key is not registered. We would like to explore if it's possible to support that, or a more graceful fallback.
Possible fixes:
- Let Glean register new extra_keys on an existing event at runtime.
gen_runtime_metrics.pywould then add them to the metrics payload, making them train-hop compatible. - Failing that, we could have Glean record the event without the unknown extra_keys instead of rejecting the whole event. This could be specific to newtab pings.
| Reporter | ||
Comment 1•1 month ago
|
||
Side note: if the Glean team has the availability, it would be great to collaborate on this during the engineering summit!
Updated•1 month ago
|
Description
•