Now that we're no longer testing FOG init instrumentation via rust-in-gtest, we
need a new thing to test in this manner or we'll delete this code and (in my
case) completely forget how we used to do this.
So let's replace the real instrumentation test with a boring one that doesn't
actually require all the boilerplate, but isn't harmed by it either.
Depends on D147450
Differential Revision: https://phabricator.services.mozilla.com/D147451
This instrumentation test has been disabled since bug 1763474 because delaying
init to this test meant that the preinit queue would overflow.
Because GoogleTest runs all at once and in its own decided order, we shouldn't
write any test that depends on FOG init happening at a specific time unless we
make it happen before the test suite even runs.
...and if we do that, the test resets that we perform in between will
obliterate the value in the init instrumentation, meaning we can't test it
anyway.
Note also that we skip-OK this test near local 4AM in case a properly-but-
inconveniently-timed "metrics" ping clears the value between FOG init and the
test run.
Now I thought we could put this in mochi, but it turns out that we reuse
browsers between test files. This means previous files' init of FOG and wiping
of all data causes the test to permafail when not run in isolation.
So here we are in xpcshell where we control init ourselves.
Differential Revision: https://phabricator.services.mozilla.com/D147448
Now that we're no longer testing FOG init instrumentation via rust-in-gtest, we
need a new thing to test in this manner or we'll delete this code and (in my
case) completely forget how we used to do this.
So let's replace the real instrumentation test with a boring one that doesn't
actually require all the boilerplate, but isn't harmed by it either.
Depends on D147450
Differential Revision: https://phabricator.services.mozilla.com/D147451
This instrumentation test has been disabled since bug 1763474 because delaying
init to this test meant that the preinit queue would overflow.
Because GoogleTest runs all at once and in its own decided order, we shouldn't
write any test that depends on FOG init happening at a specific time unless we
make it happen before the test suite even runs.
...and if we do that, the test resets that we perform in between will
obliterate the value in the init instrumentation, meaning we can't test it
anyway.
Note also that we skip-OK this test near local 4AM in case a properly-but-
inconveniently-timed "metrics" ping clears the value between FOG init and the
test run.
Now I thought we could put this in mochi, but it turns out that we reuse
browsers between test files. This means previous files' init of FOG and wiping
of all data causes the test to permafail when not run in isolation.
So here we are in xpcshell where we control init ourselves.
Differential Revision: https://phabricator.services.mozilla.com/D147448
Adds a test-only method to JS that permits the runtime registration of metrics.
Also uses that to cover JOG with tests: registering and smoke-testing metrics
of each metric type.
(Events being a notable (temporary) exception)
Instead of writing parsers, use serde_json for the optional extra metric args.
Differential Revision: https://phabricator.services.mozilla.com/D143051
Previously we used the 27th bit to signal if a metric instance was actually a
labeled_* metric's "submetric". This bit is actually part of the metric type
part of the lower (upper?) 32 bits of the metric_entry_t, but that was okay
because builtin metrics all have their top 5 bits scrubbed.
itsFreeRealEstate.jpg
This can no longer work, though, since JOG will need to be able to have its
own submetrics that don't conflict _and_ will need to keep the type bits
around so we know what instances to build.
(( Yes, yes, I could've designed the system so that we didn't need to,
but this was the less complicated way. We can go down this route when we
provision the 34 Millionth metric and run out of space. ))
So that means taking two bits away from the id portion: one for runtime (we'll
give it 2^26) and one for submetric (2^25).
Differential Revision: https://phabricator.services.mozilla.com/D143044
Now that we're no longer testing FOG init instrumentation via rust-in-gtest, we
need a new thing to test in this manner or we'll delete this code and (in my
case) completely forget how we used to do this.
So let's replace the real instrumentation test with a boring one that doesn't
actually require all the boilerplate, but isn't harmed by it either.
Differential Revision: https://phabricator.services.mozilla.com/D147451
This instrumentation test has been disabled since bug 1763474 because delaying
init to this test meant that the preinit queue would overflow.
Because GoogleTest runs all at once and in its own decided order, we shouldn't
write any test that depends on FOG init happening at a specific time unless we
make it happen before the test suite even runs.
...and if we do that, the test resets that we perform in between will
obliterate the value in the init instrumentation, meaning we can't test it
anyway.
So let's test this instrumentation in mochi where there's a little more...
control? Certainty, anyway, about how often test resets happen (never) and
whether FOG init happens (it does).
The only thing we then have to worry about that could delete this information
before we can test it is an ill-timed "metrics" ping being sent. Which is why
we skip the test between the hours of 3AM and 5AM (local).
Differential Revision: https://phabricator.services.mozilla.com/D147448
Upgrades to Glean v50.0.1, which comes with a rewritten core and
UniFFI-powered bindings.
Glean has some API changes, so we swap it over to that. Mostly mechanical changes.
Also upgrades to inherent v1.0 in fog.
This matches what Glean uses internally and gets rid of one duplicated crate.
Also upgrades to glean-parser==6.0.1
One crate duplication now (change in `python/mozbuild/mozbuild/vendor/vendor_rust.py` required).
Some new crates now vendored.
These are transitive dependencies of Glean dependencies, all with valid
licenses and already used in other products (mobile).
Differential Revision: https://phabricator.services.mozilla.com/D146062
We need to clear state at shutdown that we hold for GIFFT mirroring purposes.
However, more data can come in even later (there's nothing stopping it. Plus,
Glean can meaningfully record later given its shutdown happens in a later
phase), so the naive approach of lazy-instantiate and RunOnShutdown-clear
doesn't work.
Since Telemetry is only good to AppShutdownTelemetry, we now fail to mirror to
it after AppShutdownTelemetry and clear state in the immediately-next phase.
Also, data can come in earlier than we have a main thread to dispatch to,
requiring some careful finagling of threads to ensure our cleanup routine
is appropriately registered.
Differential Revision: https://phabricator.services.mozilla.com/D143522
