Long offline stretches explode into mass conflicts on reconnect

What it is

Offline is not a seam of minutes. It is a day, a week, a trip. The local authority works normally across that stretch; changes thicken on disk. The moment of reconnect, those changes collide with changes that happened on the cloud and other devices in the same stretch, and the conflict count jumps from “the odd sentence” to “a whole book that will not line up”. Mass conflict is a structural consequence of long offline, not an accidental bug in the sync implementation.

This leaf wants people to see the scale of the collision before reconnect finishes, and to have a way to handle it in batches — not a silent replay of hundreds of refusals.

Why it happens

Conflict probability rises roughly with the size of the two independently changed sets. A short offline: each side touches a few places, the intersection is small. A long offline: both sides used the document as their own truth, the intersection becomes a wide overlap — the same paragraph, the same task, the same permission set. Reconnect compresses time into one exchange; every overlap becomes a conflict event at once. Human handling bandwidth is one item at a time; the system’s arrival bandwidth is a flood. The mismatch yields either auto-pick and silent wide loss, or a hundred dialogs that drive the person off.

Travel also stacks clocks and stale intent. A local decision from a week ago may already have been changed by the same person on another online device; at reconnect “local truth” is not “the truth they still want”. Mass conflict is therefore not only a merge problem. It is a confrontation between expired intent and current intent. Without a preview, replay reactivates expired intent.

Where it stops holding

One person, one device, no writes on the cloud while offline: reconnect is a one-way upload, conflict scale zero, only an unsent summary. Automatically mergeable orthogonal edits (one person style, the other an attachment) should not count as “mass that needs a person”. The real explosion is the same semantic unit rewritten as body on both sides. A backup import or a device migration can manufacture “long offline” — that old laptop’s vault suddenly connects, same effect. Read-only offline has no local change to explode. If conflicts are encrypted past what the current user can read, mass handling becomes inoperable; at least list per object “this one does not line up”, even if the content cannot be shown.

Applying it

• On reconnect, a read-only preview first: how many objects will write, how many will conflict, a tappable conflict list. Do not replay immediately.
• Offer batch policy: keep all local, accept all remote, handle item by item. Do not silent-replay by default.
• Call out local intent that is obviously expired (the same person already changed that place on another device), so a week-old draft does not cover today’s final.
• How to check: device A offline seven days, twenty edits; device B online, twelve of those. A reconnects. If there is no preview, the document becomes one side’s twenty in seconds, and the other side’s labour cannot be found, that is mass silent cover. If twenty unrelated dialogs pop and cannot be skipped, scale was dumped on the person. A passing shape: one list, twelve marked conflict, eight entered automatically, the person can start from the list.

Related

• Same group: I3.10.1 Local-first treats the device copy as authoritative; the network is optional · I3.10.2 Core actions must still work with the radio off, not just remain readable · I3.10.3 Eventual consistency needs a graspable convergence story
• Nearby: I3.04 Sync conflicts · I3.11 Sync conflict merge
• Search terms: reconnect conflict · sync storm · long offline