* 1557048: Add reason codes to the metrics ping
This adds support for sending reason codes along with pings. The reason codes
are defined as an enumeration in the pings.yaml file, and only these values
are allowed on specific pings.
Additionally, this builds on that to add reason codes to the metrics ping.
* Use short form for enums
* Suppress compiler warning
* swiftlint
* NoReasonCodes -> NoExtraKeys
* Fix descriptions
With the release of Rust 1.40.0 a few new clippy lints were introduced.
For us they only apply to test code.
The following code automatically applied all of then:
cargo +nightly fix -Z unstable-options --clippy
(This autofix feature requires Rust nightly, which is 2 versions ahead
of stable as always, but the code is still valid for our minimum supported Rust version)
* Enhance `new_glean` test function to attend to all test cases
The `new_glean` function is a helper to create a new glean instance
for tests, to make code less repetitive. It didn't work for cases
when we needed to create multiple glean instances in the same test
with the same data directory. That was fixed by adding the option
to pass the tempdir as an argument to the function, thus making it
possible to call it multiple times with the same data directory.
At present, the determination of (a) whether there are too many dynamic labels
on a metric, or (b) the label is invalid, are handled synchronously in the
get() operator (in Kotlin, the bracket operator).
This requires the Glean object to already be initialized at metric recording
time -- both to see how many labels have already been used, and also to record
any errors. This both means that labeled metrics can't be recorded prior to
initialization (even though most metrics now can), but more importantly,
blocking I/O is performed to determine how many labels have already been
recorded for the metric.
This PR changes how things work so the requested dynamic label is stored on
the specific labeled metric as a new field. This dynamic label is then converted
to its actual value later as part of the coroutine task, at which point we are
guaranteed to have an initialized Glean object.
The Kotlin side is passing in `Long`, which is equivalent to `i64`.
We can store time durations as nanoseconds.
The maximum value that a `u32` can represent in nanoseconds is barely
over 4 seconds.
It's easier if we just store it in a larger integer.
* 1557366: Clear metrics when uploading is disabled
* Address comments in PR
* Test that re(en/dis)abling is a noop
* Address comments in the PR
* Fix Kotlin warning
* Merge with events changes
Beatriz Rizental
Jan-Erik Rediger
Michael Droettboom
Alessio Placitelli
Beatriz Rizental
Travis Long