-
Notifications
You must be signed in to change notification settings - Fork 123
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
1557048: Add reason codes to the metrics ping #649
Conversation
d3fd05f
to
bc6429e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wow, that was unexpectedly big :o Thanks for tackling it. Leaving a few comments, as I'd like to take another pass after the glean parser changes land.
glean-core/android/src/main/java/mozilla/telemetry/glean/private/PingType.kt
Outdated
Show resolved
Hide resolved
glean-core/android/src/main/java/mozilla/telemetry/glean/scheduler/MetricsPingScheduler.kt
Outdated
Show resolved
Hide resolved
glean-core/android/src/main/java/mozilla/telemetry/glean/scheduler/MetricsPingScheduler.kt
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do the changes to metrics.yaml and pings.yaml result in any changes to the docs? I was expecting more markdown files in this PR.
c0c2893
to
24a044a
Compare
@travis79 : Any thoughts on the failure in the iOS integration test? I can't reproduce locally, i.e.:
works for me. I suspect this has something to do with how the integration test build is "special"? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left a couple of comments, but I want to take a deeper look tomorrow to build locally and see if I can make some concrete suggestions.
0c0158b
to
0997bad
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First high level view pass, nitpicking on sent vs submitted
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First high level view pass, nitpicking on sent vs submitted
*/ | ||
internal fun submitPingsByNameSync(pingNames: List<String>) { | ||
internal fun submitPingsByNameSync(pingNames: List<String>, reason: String? = null) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please note that pingNames
can potentially contain names of different pings (e.g. baseline
, events
) and we're only passing a single reason: we should probably have a list of pairs or a map, or two lists in order to match specific optional reasons to specific ping names.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a good point, and I agree this is a problem. Passing in "parallel lists", one of which is optional, seems kind of a strange API though (at least it's internal API).
I actually feel like it might be better to remove all of the plural submit "pings" in favor of a single submit "ping" on all of these functions. We only use this to submit multiple pings in one place, and we don't even get any parallelism out of thing by batching them up like this. I think that would be a useful simplification.
Thoughts? @Dexterp37, @badboy, @travis79, @brizental ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess, specifically, what I'd propose is to merge this PR as-is with respect to this, and as follow-on work, replace submitPings*
with submitPing
, which would fix the ambiguity around reason codes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One other reason we went with submitPings
(multiple) was to only call into Rust once.
So far no one has ever complained about FFI calls and given how infrequent and with how small of a list we call it I'm fine with dropping that API
(Users can only submit one ping at a time anyway, through the CustomPing.submit()
function, right?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm all for the one at a time, one ping with one reason passed into the function. I also like the idea of this simplifying the underlying FFI function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@badboy: Yes, through the public API, users can only submit one ping at once. The only place where we submit multiple is on going to background (to send baseline and events).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with dropping the plural, but I think it needs to be part of this PR, since this makes #687 buggy (unless we opt for sending the ping on background without a "reason" code.) :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, good point about #687. I was mainly just trying to not make this PR any bigger than it already is. But it should be straightforward. I'll take it on.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I gave this a very rough first pass.
What I would like to see is describing the "why" in the commit message.
Things like highlighting that the reasons are statically defined and become enums as part of the Ping type on the platform side.
glean-core/android/src/main/java/mozilla/telemetry/glean/private/PingType.kt
Outdated
Show resolved
Hide resolved
glean-core/android/src/test/java/mozilla/telemetry/glean/GleanTest.kt
Outdated
Show resolved
Hide resolved
Codecov Report
@@ Coverage Diff @@
## master #649 +/- ##
=============================================
+ Coverage 75.52% 87.57% +12.05%
- Complexity 266 268 +2
=============================================
Files 98 59 -39
Lines 6191 2971 -3220
Branches 751 126 -625
=============================================
- Hits 4676 2602 -2074
+ Misses 969 312 -657
+ Partials 546 57 -489
Continue to review full report at Codecov.
|
af91250
to
534191d
Compare
I think this beast is finally ready for a final review. Apologies for how out-of-hand it became. EDIT: So, close, but Android tests:
And with that fun, I'm out for the day. |
e946fd2
to
e4a78ae
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. What was that bad failure about? What was the fix?
I was never able to see the segfault again. The other intermittent was unrelated to this PR, it turned out, and fixed in #692. |
glean-core/android/src/test/java/mozilla/telemetry/glean/private/LabeledMetricTypeTest.kt
Outdated
Show resolved
Hide resolved
glean-core/android/src/test/java/mozilla/telemetry/glean/private/LabeledMetricTypeTest.kt
Outdated
Show resolved
Hide resolved
Good catch. 👍 on fixing that.
…On Thu, Feb 6, 2020, 1:32 PM Travis Long ***@***.***> wrote:
***@***.**** requested changes on this pull request.
------------------------------
In
glean-core/android/src/test/java/mozilla/telemetry/glean/private/LabeledMetricTypeTest.kt
<#649 (comment)>:
> @@ -397,15 +397,15 @@ class LabeledMetricTypeTest {
@test(expected = IllegalStateException::class)
fun `Test that labeled events are an exception`() {
- val eventMetric = EventMetricType<NoExtraKeys>(
+ val eventMetric = EventMetricType<NoReasonCodes>(
Did you mean to change this here? I think NoExtraKeys is correct for an
EventMetricType.
------------------------------
In
glean-core/android/src/test/java/mozilla/telemetry/glean/private/LabeledMetricTypeTest.kt
<#649 (comment)>:
> disabled = false,
category = "telemetry",
lifetime = Lifetime.Application,
name = "labeled_event_metric",
sendInPings = listOf("metrics")
)
- val labeledEventMetric = LabeledMetricType<EventMetricType<NoExtraKeys>>(
+ val labeledEventMetric = LabeledMetricType<EventMetricType<NoReasonCodes>>(
I don't think you meant to change this here, I think NoExtraKeys is
correct for an EventMetricType.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#649?email_source=notifications&email_token=AAAJLFR2HURLC4P3U3RX3A3RBRJVVA5CNFSM4KGZYVO2YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCUR6EBA#pullrequestreview-354673156>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAJLFWLV54FXUBR4H3MSSLRBRJVVANCNFSM4KGZYVOQ>
.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mostly skimmed it, and it looked fine. I have Feelings about how the descriptions should be approached, though.
5db0b11
to
cf5d803
Compare
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.
bdb369d
to
8595861
Compare
Requires mozilla/glean_parser#157 and mozilla-services/mozilla-pipeline-schemas#484 to be merged first.
This was a real iceberg.
Also, no Swift or Python support yet, but thought it worth getting feedback on this much first.