Firefox Desktop is (at present) unique amongst Glean SDK embedders in that it has multiple app ids (
firefox_desktop_background_update (and soon also
firefox_desktop_background_tasks)) all served from the same binary.
We make this work in the pipeline by slicing up
metrics_index.py into segments by app_id, and using that to inform the pipeline which app has which metrics and pings. This stops e.g.
firefox_desktop_background_update from having a "newtab" ping, or any of its
However, since the lists of metrics and pings available within the client are determined by
glean_parser at compile time,
firefox_desktop_background_update can indeed submit a "newtab" ping and the SDK won't stop it. More importantly: any data that is to be sent in another app_id's ping will be successfully stored even though that app_id doesn't intend to send it and the pipeline isn't set up to receive it if it did.
In Glean v51 and earlier this was self-limiting. The maximum size of non-
event metrics is fixed (thank you, Sensible Limits as an architectural choice), and
event metrics would trigger the pings to be submitted automatically by the SDK. (See bug 1787918 and its friends for how the pipeline felt about this)
With bug 1716725 (coming in Glean v52) we've addressed the problem of the SDK sending another app_id's pings automatically just because there are events stored in it. But this puts us in the position where now we may store unlimited numbers of
This is bad. What should we do about it?