1168890 - Handle X-Weave-Backoff

Status: RESOLVED FIXED

(Firefox for iOS :: Sync, defect)

Description

[Richard Newman [:rnewman]]

We want to handle protocol-level backoffs, of course.

In the course of implementing timed syncs (Bug 1168501), though, we also need to make sure that we don't repeatedly hammer a user's battery life and data allowance by failing over and over.

Comment 1

[Richard Newman [:rnewman]]

Attachment: Pull req.

This puts backoff handling inside the storage client, using a state hook to persist into prefs.

This is much, much simpler than inspecting the response in each synchronizer.

There are two ways we can get a backoff: inside a success response, or as part of a failure response.

The latter still fails. The former still succeeds. But in the former case, the *next* request will now fail due to outstanding backoff. Which is exactly what we want to happen.

We also check for outstanding backoffs, via the storage client itself, when starting to sync each synchronizer -- better then than having the first request fail.

Tested manually by forcibly returning backoff values in updateBackoffFromResponse.

(I really, really want to get a testing service into the tree so we can write some proper tests for this, but alas now is not the time.)

Comment 2

[Nick Alexander :nalexander [he/him]]

Comment on attachment 8613851 [details] [review]
Pull req.

I gave this a quick scan only, but it looks sensible.

Consider not hard-coding the string ("backoff.server...") and varying the Prefs object.  That's a surprising pattern, I think.  I think fixing the Prefs and varying the string is more expected.  (Consider we might want this for FxA and token server, etc.)

Comment 3

[Richard Newman [:rnewman]]

Legit point. Will do.

Comment 4

[Richard Newman [:rnewman]]

Piss, I think I forgot to do the prefs object change. Will file a follow-up.

https://github.com/mozilla/firefox-ios/commit/51cd63aab90f6c063f1c4909b419c2b9798247a6