838291 - Better APIs for payload retrieval

Status: RESOLVED FIXED

(Firefox Health Report Graveyard :: Client: Desktop, defect)

Description

[Gregory Szorc [:gps]]

Attachment: Changes to payload retrieval APIs, v1

This patch fixes some deficiencies with the existing "get FHR payload" flow:

a) There was no single API for "collect then get payload"
b) about:healthreport was relying on an upload to occur before the payload could be displayed
c) about:healthreport was deserializing JSON from disk then reserializing it to pretty print.

b & c are somewhat related.

In this patch, we now have a unified "collectAndObtainJSONPayload" API. It does what its name implies. It's guaranteed to always return the most up-to-date payload possible.

about:healthreport now calls the aforementioned API when the "show details" button is pressed and the raw JSON is displayed. This has the following implications (hence the f? from mconnor and dre):

* You will likely never see the "no data available" message because we will always collect before displaying.
* You will always see all data known to FHR, not the last submitted payload.
* You will not see the last submitted payload.
* There may be a lag between when the button is pressed and when data has finished collecting. But it's async, so, ok?

I think the user benefit of this change is that "show details" will now always show information. Users will not need to wait for ~24 hours for data to become available. I'm not a UX expert, but I think it would be better for people to have immediate gratification of seeing *some* raw data instead of none. I could imagine some users [like me] will think "I just enabled this feature and it won't show me what it is submitting - that feels like a bait-and-switch - disable."

If we want to nix the changes to about:healthreport from this patch, I'm OK with that. The core APIs can stand on their own.

Let the bikeshedding begin.

Comment 1

[Richard Newman [:rnewman]]

My initial 2¢:

* If we have a saved payload, show it: don't always collect. That'll probably improve responsiveness for the about page (slurp JSON rather than run a bunch of DB queries), and also shows what we sent.

That means we need to be able to ask FHR "give me the last JSON payload, collecting if we don't have one", and "collect a new payload and give it to me".

I don't mind whether that's a flag ("collect if necessary", "always collect", "don't collect") or a separate method, but I think triggering a collection every time a user refreshes about:healthreport is a bad idea. What if they leave it open in a tab, and we restore that page every time they relaunch Firefox?

* Yes, please separate out the UI changes.

Comment 2

[Richard Newman [:rnewman]]

> * Yes, please separate out the UI changes.

Actually, I take that back. Trivially small.

Comment 3

[Richard Newman [:rnewman]]

Comment on attachment 710330 [details] [diff] [review]
Changes to payload retrieval APIs, v1

Review of attachment 710330 [details] [diff] [review]:
-----------------------------------------------------------------

This'll do for now, IMO.

Comment 4

[Gregory Szorc [:gps]]

https://hg.mozilla.org/services/services-central/rev/65e0a461f1ef

Removed change to about:healthreport before commit. Can deal with it in a follow-up.

Comment 5

[Gregory Szorc [:gps]]

https://hg.mozilla.org/mozilla-central/rev/65e0a461f1ef