Open Bug 1350963 Opened 7 years ago Updated 2 years ago

Handle timeouts and responses to bookmark repair command

Categories

(Firefox for iOS :: Sync, enhancement)

Other
iOS
enhancement

Tracking

()

People

(Reporter: sleroux, Unassigned)

References

Details

(Whiteboard: [Q2 OKR])

After we've sent off the repair request to a desktop client, a couple of things can happen:

1. At some point in the future a desktop client writes a repairResponse command to our client record with the problematic IDs we requested that it sent to the server.
2. We never hear back from a desktop client. 

In case (1), we'll want to diff the IDs the desktop client sent to the server with the ones we asked for and see if there are any remaining IDs that need resolution. Otherwise, stop. If there are remaining IDs that need resolution, we should re-request the same desktop client. Re-requesting the same client should only happen up to a maximum of 5 times before moving onto a new client.

In case (2), we should wait a maximum of 3 days from the time we requested and timeout. At this point we will send another repair command to the next best desktop client. Next best in this context meaning a client that has most recently synced and runs Firefox => 54.

The information received from response and sent in a request should progress the state machine. For example, when we receive IDs from a repairResponse, we should add that to our request state and pass it along to our request process.
Whiteboard: [Q2 OKR]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.