Expiry for TypedURLSyncBridge is convoluted and brittle |
|||
Issue descriptionWhen an URL gets expired, the bridge deletes the metadata locally and does not sync the deletion up to the server. The reasons are to a) save server storage by not storing tombstones (major); b) protect against expiration rampage of a client with a bad clock (major); c) save traffic (minor). The server expires typed url data independently without creating tombstones. This works now because we only need eventual consistency. We do not mind if, for instance, a client locally expires an URL, the server expires it independently, another client syncs it up again (because its clock is shifted) and pushes it to the first client that again has to expire it locally. This is brittle: - the invariants in the client side code are hard to argue about, - it relies on the server not doing any conflict detection (when a client expires and URL locally and the user re-types the URL before it gets expired on the server, we create an entry that we believe is new but it actually overwrites the previous entry).
,
Jun 12 2018
,
Jun 12 2018
The conflict detection brittleness is (most likely) tested by this test: TwoClientTypedUrlsSyncTest.AddThenExpireThenAddAgain
,
Jun 14 2018
|
|||
►
Sign in to add a comment |
|||
Comment 1 by jkrcal@chromium.org
, Jun 12 2018