Should Burnham use the client activity API?

[badboy]

Is your feature request related to a problem? Please describe.

Glean now provides the client activity API.
It is not yet implemented for Python.
This allows embedding applications to trigger behavior based on client activity.
On mobile this maps to foregrounding (active) and backgrounding (inactive).
For Desktop this maps to certain activity within a certain amount of time.

The API triggers the baseline and events ping, both otherwise internal pings.

Describe the solution you'd like

Would it be useful for burnham to use this API to simulate activity and thus test Glean's expected behavior around those pings?

[hackebrot]

Yes, I think adding meaningful test coverage for the client activity API would be useful! 👍🏻

[badboy]

Ok, let's design one! (As said, the implementation is not yet done, but should be available in the next release then)

[hackebrot]

Status update: @badboy will bring this to the team's attention today. 🚧

[badboy]

We currently don't have the time to pick up this work.

[hackebrot]

Hi @chutten! 👋🏻

From what I understand FOG is one of the consumers of the activity API. Do you have any thoughts or suggestions for how we can meaningfully test this API with burnham?

[chutten]

Yup, FOG certainly is using the client activity API to signal activity (which Glean turns into "baseline" pings, as well as an opportunity to send "events" pings). Burnham could use these APIs to ensure pings are sent with the appropriate reasons at the appropriate times (and in the appropriate numbers) by simulating normal use (actives followed by inactives followed by actives) and error cases (what happens if we call active twice in a row? inactive? What if the first API call is to inactive instead of active?)

This would be important for understanding the failure modes of the client activity API and how visible they are in the data. Maybe FOG's misusing the API in a way that is presently invisible?

[hackebrot]

Thank you for adding your input, @chutten! 👍🏻