Clarification around data.days entries

[Richard Newman]

> Ah, interesting, and surely different than what I would expect, though it makes sense. I guess we should have everything documented that gets explained in this thread. ;-)

We have some documentation that implies much of this, but let me know if you'd like more clarity.

https://hg.mozilla.org/mozilla-central/file/5dc091b7e86f/services/healthreport/docs/dataformat.rst

App sessions in Version 3
-------------------------

Sessions are divided into "normal" and "abnormal". Session objects are stored as discrete JSON::

    "org.mozilla.appSessions": {
      _v: 4,
      "normal": [
        {"r":"P", "d": 123},
      ],
      "abnormal": [
        {"r":"A", "oom": true, "stopped": false}
      ]
    }

Keys are:

"r"
    reason. Values are "P" (activity paused), "A" (abnormal termination).
"d"
    duration. Value in seconds.
"sg"
    Gecko startup time (msec). Present if this is a clean launch. This
    corresponds to the telemetry timer *FENNEC_STARTUP_TIME_GECKOREADY*.
"sj"
    Java activity init time (msec). Present if this is a clean launch. This
    corresponds to the telemetry timer *FENNEC_STARTUP_TIME_JAVAUI*,
    and includes initialization tasks beyond initial
    *onWindowFocusChanged*.

Abnormal terminations will be missing a duration and will feature these keys:

"oom"
    was the session killed by an OOM exception?
"stopped"
    was the session stopped gently?



>>> What about ones that have been unexpectedly terminated, do we detect and record those correctly?
>> Orphans are detected and flushed on next startup.
> 
> Hmm, that sounds like we'd miss out on info about sessions where we crash or otherwise die. Don't we want to do stats on those?

No, we reliably detect failures. We just -- obviously -- can't detect them and write them into the database until our activity is relaunched. We don't get durations for those crashed sessions, because we're not willing to expend the write load to constantly persist a duration.