Sync delay produces inconsistent state across devices
Aliases: eventual consistency · Chrome tab sync · stale replica · sync lag
What it is
A tab just closed on the computer is still sitting in Chrome on the phone; a document edited on the phone is the previous version on the laptop. Both sides “have the thing,” frozen at different times. Inconsistency from sync delay is not a continuation that failed to hand over an activity. It is multiple devices holding replicas that have not caught up. People treat “I just changed that over there” as a global fact; delay splits that fact into two worlds. This entry is about old and new coexisting because of time. It is not about who wins when both sides edited, and not about whether read marks should arrive before the body.
Why it happens
Cross-device sync is almost always eventual consistency: write locally, then find a chance to reach the server and the other devices. That chance depends on network, power policy, and whether the app is foregrounded. A phone frozen in the background leaves the computer’s edits as a stale replica; the reverse is the same story. People do not think in replicas. They think “my stuff”—what just happened on A should already have happened on B. Once the delay outlasts the few seconds of a device switch, B’s old state is taken as truth: a closed tab is reopened, an edited sentence is edited back, a played episode starts over. Without a “still catching up” signal, the stale state looks finished, so people do not wait—they act on an expired world and turn delay into a new fork.
Studying it
Diaries and logs from multi-device ecologies catch the moment of “I thought the other side was already new.” In the lab, a two-device readout: same account, a visible change on A, an immediate read on B, recording how long B takes to catch up and which wrong moves happen in between.
Independent variables: sync trigger (immediate, on foreground, periodic), network and power constraints, presence of a “still syncing” signal. Dependent variables: wait until both sides agree, misoperations based on stale state, attribution to “I didn’t save” versus “it is still transferring.”
Server-side commit is not user-side agreement; people judge the other screen. Lab networks beat a commute, so measured delay runs short. Diaries must split “content has not arrived” from “it arrived but I cannot find it”—the latter is not sync lag.
Where it stops holding
Work finished on one device with no immediate switch never feels the delay. Locally authoritative data (audio still being recorded, camera roll not yet uploaded) is allowed to lead; mark “not on other devices yet” rather than pretending global agreement. Once a conflict already exists, the problem is a rule, not speed. Weak networks and airplane mode are delay at its limit: go explicitly offline instead of showing an interface that looks live and is frozen.
Applying it
- On the surfaces people switch to most, show that sync is incomplete: a tab list marked “still updating,” a document labeled “edits from the computer have not arrived,” so a stale list is not presented as done.
- Pull on foreground; do not wait for the next periodic pass. Delay budgets on a device-switch path are seconds, not minutes.
- Push first the objects that cause misoperation (open tabs, the draft being edited, playback position); large attachments can lag.
- Verify by closing several Chrome tabs and editing a cloud document on the computer, then immediately opening the phone on the same account. Until sync completes, the phone must not present closed tabs and the old document as settled current state; remaining old values must be readable as “not caught up.”