1216347 - [convoy/cronsync] Implement network usage failsafe by tracking network budget.

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::E-Mail, defect)

Description

[Andrew Sutherland [:asuth] (he/him)]

In bug 1013373 it appears there was a scenario where periodic sync used wayyy too much data.  It is definitely within our power to track within an order of magnitude our network use.  (Maybe even better if we can use the WebAPI).

I would propose that for our convoy cronsync implementation that we:

- Track the amount of data used as one of the statistics logged from each periodic sync attempt.  This would accompany other stats like "number of messages we heard about from all mail that we didn't care about" as well as the number we did care about.  Also synced conv count, synced message count, snippet data fetched, and so on.

- Have cronsync put itself into a degraded mode of operation and alert the user if it thinks it is using too much data.  "too much" would have a few heuristics:

  - "we're paying too much".  We can establish reasonable bounds for the costs of syncing a message.  If we're going way outside that cost window, then something is going wrong.

  - "this is unusual".  In general I think we would expect users to experience a steady-state flow of email which we can probably characterize as messages per day.  If the traffic alters greatly, especially if it's churn without actual new messages (which could indicate a serious sync algorithm failure).

  - "this is high in absolute terms".  We could set an amount of daily data usage that we think is reasonable as a default, and if we cross it, we can ask the user to approve setting a higher limit.  If they don't want a higher limit, we can propose reducing our sync interval.  (And if they do, we can also give ourselves a fake "data refund" proportionate to the new sync interval so we don't immediately trip ourselves.)

The user-visible aspects of this would be:
- Letting the user know we think something's wrong and asking them to report the telemetry data to us in a bug report or via other telemetry avenue.
- Letting the user alter our data budget.
- Erring on the side of not using data, but providing an explicit notification if we automatically degrade our sync interval or disable periodic sync entirely.

Comment 1

[BMO Automation]

Firefox OS is not being worked on