On reconnect, announce and sync what changed offline

What it is

The network returning is not finished when the offline banner is quietly taken down. Local things may have changed while offline, and so may remote things. Announcing and syncing on reconnect means the UI declares “online now,” sends (or pulls) queued changes, and states the outcome of that round. Three comments written on a train, with no aftermath after leaving the tunnel, leave people unable to tell whether the other side saw them. Reconnect is an event, not the banner’s exit animation.

Why it happens

Offline splits the user’s world model from the server’s. Reconnect is the merge. If the merge is not announced, people keep acting on the offline model: they dare not quit, they tap send again, or they assume sync happened and tell someone “I already sent it.” An explicit notice puts the merge in the foreground: sync starting, in flight, done or conflicted. It also has to handle timing—the person may be doing something else at reconnect—so the notice must not steal current input, and must not stay silent until the merge is over and nobody knows it occurred. Silent success is especially dangerous here: a drained offline queue and “never actually sent” look the same if the only signal is that the banner vanished.

Where it stops holding

If every jittered reconnect prompts once, the notice becomes noise; announce after stable online, and fold reconnects inside the jitter window into one sync round. When there were no offline changes and no new remote changes, taking down the offline state is enough; there is no need to celebrate “connected again.” Conflicts need object-level handling; one “synced” must not cover them. If the user starts editing an object while a background sync of that object is in flight, the notice should make clear that this sync has not yet landed, or the typing will be overwritten.

Applying it

• After connectivity is stably back, announce once and start the queue. Continue with “syncing / synced / conflict” on the objects, not only by removing a banner.
• At the end of sync, give a scannable outcome: n sent, n pulled, n conflicts, with conflicts opening to the object.
• Keep the reconnect notice non-modal so it does not interrupt current typing, but it must appear.
• Verify by changing two items offline and restoring the network without tapping any sync control. If the UI has no aftermath, reconnect was implemented as a banner disappearing.

Related

• Within the group: E6.14.1 Show offline status before the action, not after submit fails · E6.14.2 Say whether offline actions will queue for retry · E6.14.4 Long-term offline use depends on how complete local data is
• Adjacent: E6.04 Global status messages · E6.13 Inline result presentation · E6.12 When notices dismiss
• Search terms: reconnect · sync on online · offline merge