Nick Alexander :nalexander [he/him] (PTO until Montreallhands August 21, 2023) Reporter
	Description • 11 years ago

Related to Bug 726055 but not tracked there yet.

We should add a periodic sync, contingent upon your Firefox Account state:

* if your account is invalid or needs updated credentials, never;
* if your account is waiting to be verified, aggressively (we want to drive conversions, and react to verification ASAP);
* if your account is syncing and you're the only device, infrequently;
* if your account is syncing and you're part of a a constellation of devices, frequently;
* if your account is in an error state, very infrequently.

http://developer.android.com/reference/android/content/ContentResolver.html#addPeriodicSync%28android.accounts.Account,%20java.lang.String,%20android.os.Bundle,%20long%29

	Richard Newman [:rnewman] Assignee
	Comment 1 • 11 years ago

Intuition suggests that the periodic syncing interface isn't designed for very short intervals, as we'd want for the verification waiting period, so perhaps we'd be better off with a small alarm-driven service for that? Would allow for more persistent state, too.

Also need to make sure that an interruption in verification -- e.g., a user who wanders off, doesn't have that email account set up on their phone yet, etc. -- doesn't result in killing their battery. Needs an exponential backoff, I imagine, and adjusting to match the network state.

And a final note: for the routine state of affairs (3 and 4), we need to make sure that the internal rate limiting is adjusted to match (or replaced by an Android-native equivalent). No sense having the system trigger syncs more frequently than we're set up to allow.

	Richard Newman [:rnewman] Assignee
	Comment 2 • 11 years ago

Early feedback, please.

	Richard Newman [:rnewman] Assignee
	Comment 3 • 11 years ago

This pull req covers tracking and checking backoff for an abstract "scheduling" concept, the token server, and the current storage server. It wires in a BackoffHandler into the normal spot to handle GlobalSession backoff notices, and also tracks token failures.

This also schedules periodic syncs to match the number of clients and backoff notices.

Needs tests (and testing), but it's getting there.

	Nick Alexander :nalexander [he/him] (PTO until Montreallhands August 21, 2023) Reporter
	Comment 4 • 11 years ago

rnewman: this is reviewed but not landed, right?

	Richard Newman [:rnewman] Assignee
	Comment 5 • 11 years ago

(In reply to Nick Alexander :nalexander from comment #4)
> rnewman: this is reviewed but not landed, right?

Correct. James and I are planning a QA session this morning to exercise all of the backoff cases.

I put together a test plan:

https://etherpad.mozilla.org/fxa-sync-backoff-test-plan

and addressed all of the success cases already, so we're just in error-handling land now.

	Richard Newman [:rnewman] Assignee
	Comment 6 • 11 years ago

Carrying forward review, even though I fixed some things after today's marathon QA session.

	Richard Newman [:rnewman] Assignee
	Comment 7 • 11 years ago

https://hg.mozilla.org/integration/fx-team/rev/dd12b3213d88

	Ryan VanderMeulen [:RyanVM]
	Comment 8 • 11 years ago

https://hg.mozilla.org/mozilla-central/rev/dd12b3213d88

	Richard Newman [:rnewman] Assignee
	Comment 9 • 11 years ago

Comment on attachment 8376016 [details] [diff] [review]
Final patch.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 
  FxA Sync.

User impact if declined: 
Testing completed (on m-c, etc.): 
  m-c and QAed.

Risk to taking this patch (and alternatives if risky): 
String or IDL/UUID changes made by this patch:

	Richard Newman [:rnewman] Assignee
	Comment 10 • 11 years ago

https://hg.mozilla.org/releases/mozilla-aurora/rev/554e17cd4f4b