1685522 - Implement the 'baseline' ping scheduling in the RLB

Status: RESOLVED FIXED

(Data Platform and Tools :: Glean: SDK, task, P1)

Description

[Alessio Placitelli [:Dexter]]

This bug is about implementing the 'baseline' ping scheduling. On non-mobile platform the concept of "activity" may vary. For this reason, we may need to expose a new API:

• set_inactive to signal glean-core that the product is now inactive (e.g. going to background on mobile)
• set_active to signal glean-core that the product is now active (e.g. going back to foreground on mobile)

The same APIs can be used in FOG to model different concepts of activity. Prior art is available in this document.

@chutten, @janerik what do you think of this API? Do you want me to write a short proposal?

Comment 1

[Jan-Erik Rediger [:janerik]]

This API is only exposed on the RLB, not on glean-core directly then, correct?
I wonder if we can have a bit more self-explanatory naming. A short proposal would be good so we can clarify what behavior we expect (that is: which pings to trigger).

Comment 2

[Chris H-C :chutten]

Yeah, a proposal might be a good plan. I don't feel too happy about set_(in)active but I honestly can't think of anything better short of exposing the "baseline" Ping object directly so RLB consumers call .submit on it directly.

Comment 3

[Jan-Erik Rediger [:janerik]]

Question is: is there actual state to handle inside RLB/glean-core for set_(in)active?
I guess the only thing it does is to automatically set the reason based on this.

Comment 4

[Jan-Erik Rediger [:janerik]]

Should have read the code first.
It also starts/stops the baseline duration, background (=inactive) also sends the events ping

Comment 5

[Alessio Placitelli [:Dexter]]

Here's my short proposal: https://docs.google.com/document/d/1aISzfODLje2QtB3Z8P4A9ii-QE2kemqijQJ3VKMmOF0/edit#

Chris, Jan-Erik, thoughts?

Comment 6

[Chris H-C :chutten]

It is straightforward and will get the job done. Leaving the ni on me because I think we should first answer the questions about using bg/fg terminology in contexts where those actions aren't the trigger.

Comment 7

[Jan-Erik Rediger [:janerik]]

high-level signoff from me, left some detail questions on the proposal.

Comment 8

[Alessio Placitelli [:Dexter]]

Hey Jeff, Frank!

Do you know if anyone uses the 'baseline' ping reasons to produce specific analyses or dashboards? At some point I remember the background/foreground reasons of the 'baseline' ping were used in some ETL to produce a dashboard for executives. Am I misremembering?

Comment 9

[Jeff Klukas [:klukas] (UTC-4)]

When originally implementing reason=foreground, we excluded it from ETL for stability. We then did some analysis to justify that we understood the behavior and that it was reasonable to include, then we removed the reason=foreground restriction. I am not aware of any current mobile ETL that depends on baseline ping reason.

Related:
https://bugzilla.mozilla.org/show_bug.cgi?id=1627286
https://jira.mozilla.com/browse/DS-1018

Comment 10

[Chris H-C :chutten]

The naming conversation seems to be winding its way to a satisfactory conclusion. Removing ni?.

Comment 11

[Alessio Placitelli [:Dexter]]

(In reply to Jeff Klukas [:klukas] (UTC-4) from comment #9)

When originally implementing reason=foreground, we excluded it from ETL for stability. We then did some analysis to justify that we understood the behavior and that it was reasonable to include, then we removed the reason=foreground restriction. I am not aware of any current mobile ETL that depends on baseline ping reason.

Awesome, thank you Jeff! This is what we were hoping. Looks like we can move on renaming the 'reason' for the 'baseline' ping. Worst case, Frank outlined a potential fallback plan in case we find people were relying on the reason (in the doc).

Comment 12

[GitHub Bugzilla PR Linker]

Attachment: Link to GitHub pull-request: https://github.com/mozilla/glean/pull/1455