This patch is a potential improvement to handling of event_context parse errors.
At the point of instrumentation we have the Event Context as a `String`. When we created this error metric, our expectation was that we would get only (or at least primarily) JavaScript `Object`s that we would want to parse, check for fields, etc. Failure to parse via `JSON.parse()` was then expected to be mostly for cases where fields were malformed, contained illegal data, etc. In practice, it turned out that we mainly receive things that look like they ought to be `String`s after all.
This change imposes two small requirements that make it much more likely that when we see a parse error that the resulting increment is actually giving us valuable information.
Differential Revision: https://phabricator.services.mozilla.com/D179612
We consolidate all the "messaging-system"-namespace pings into a single Glean
ping to provide a holistic view of all events in that system.
Differential Revision: https://phabricator.services.mozilla.com/D178477
The schema still imposes the following restrictions:
- Having "template" present makes "content" and "id" required.
- Having "content" present makes "template" and "id" required.
Template and content are dependent on eachother because we do not know how to
interpret content without a template and we a template with no content to
interpret is useless.
If we have a template and content, then we also need an ID for the message
because we cannot reference the message content except by its ID.
Differential Revision: https://phabricator.services.mozilla.com/D172458
The schema still imposes the following restrictions:
- Having "template" present makes "content" and "id" required.
- Having "content" present makes "template" and "id" required.
Template and content are dependent on eachother because we do not know how to
interpret content without a template and we a template with no content to
interpret is useless.
If we have a template and content, then we also need an ID for the message
because we cannot reference the message content except by its ID.
Differential Revision: https://phabricator.services.mozilla.com/D172458
This also fixes a bug in ASRouter devtools that prevented evaluation of
expressions containing nested promises. Objects containing promises are now
correctly serialized to the ASRouter devtools and expressions evaluate
correctly.
Differential Revision: https://phabricator.services.mozilla.com/D169408
This also fixes a bug in ASRouter devtools that prevented evaluation of
expressions containing nested promises. Objects containing promises are now
correctly serialized to the ASRouter devtools and expressions evaluate
correctly.
Differential Revision: https://phabricator.services.mozilla.com/D169408
This also fixes a bug in ASRouter devtools that prevented evaluation of
expressions containing nested promises. Objects containing promises are now
correctly serialized to the ASRouter devtools and expressions evaluate
correctly.
Differential Revision: https://phabricator.services.mozilla.com/D169408
This commit trades away consistency in order to reduce code execution.
Hopefully this avoids executing code that is likely not "shutdown
safe" and is inadvertently restarting services or otherwise hanging
when run during shutdown.
The trade off is that the written targeting snapshot may now be
incomplete (which was always the case in the face of runtime errors,
e.g., corrupt a database) or internally inconsistent (which is
probably new). For example, weekly usage could be populated but most
frecent sites could be empty, contradicting the usage. This trade-off
is accepted: occassionally targeting the user "in the
past" (generally, with data captured 30 minutes ago) is preferable to
relatively frequent shutdown crashes.
I would have liked to have checked for `shuttingDown` in
[CachedTargetingGetter](https://searchfox.org/mozilla-central/rev/abf6758ed833c203f84703aa2e3e3d317571b1e9/browser/components/newtab/lib/ASRouterTargeting.jsm#152),
but doing so might throw exceptions (or inject `null` values) where
they were not anticipated, which carries risks that I couldn't easily
mitigate.
If the measure implemented here is ineffective, we'll likely need to
restrict the set of targeting data collected, but I hope to avoid
that, since it reduces the flexibility of the background messaging
targeting significantly, and we may want the agility provided by rich
targeting at an unknown time in the future.
Differential Revision: https://phabricator.services.mozilla.com/D165916
