Telemetry+FHR v4: Submission policy

[Nicholas Alexander]

On Mon, Jan 26, 2015 at 11:01 AM, Brendan Colloran <bcolloran at mozilla.com>
wrote:

> In the design doc--
>
> https://docs.google.com/a/mozilla.com/document/d/1IGpzsYGi_sq3YFQDAPyKOkU_BKvXAC95fZYA2i4ceVs/edit#heading=h.kdz9l9vsn2d9
> -- we have the following:
>
> """
> Ping Retention and Upload
>
> Pings are saved on the client for a period of time (180 days for main
> pings; may be shorter for other pings types). As soon as a ping is
> complete, it is sent to the Mozilla analysis server. In case of
> sending errors, the client will retry several times. The client
> assumes that once it has received a 200/201/202 HTTP response for a
> ping, that it has been received successfully.
> """
>
> I thought we'd discussed the need to keep trying to resubmit a session
> fragment until an ack is received (i.e., two times will not
> necessarily be enough). I would certainly be worried about data loss
> if we make at most two submission attempts.
>


My confusion begins.  I understand Android best, so I'll speak to what we
do there.  We should not lose FHR data even if some long sequence of
submission attempts fails, because the FHR document rolls up 180 days of
data.  So if you fail all day Monday but succeed on Tuesday, you still see
Monday in Tuesday's submission.  Our policy merely means we won't hammer
your connection failing to upload; we'll try 3 times a day, everyday.  I
haven't a clue how this interacts with Telemetry.  I would note that
whatever retry policy we implement, we must assume that devices will be
disconnected for arbitrarily long periods of time.

Yours,
Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/fhr-dev/attachments/20150126/9d53b985/attachment.html>