A live connection can drop while the server continues to change records. The client needs a version or event sequence so it can recognize an older update and a gap. An event ID allows a stream implementation to resume when the server retains history; otherwise the client must refetch the current record after reconnect. A message's arrival order is not always the business order across workers or transports. The UI should apply an event only when its version is newer than the version already displayed, then decide what to do if versions jump.
Make this comfortable
Live Update Reconnect and Event Ordering
Working case
Case 47 is at version 12. The browser receives an approval event for version 14 after a temporary disconnect, but never saw version 13. It fetches the current case snapshot before displaying the final status. Later, a delayed version-13 event arrives and is discarded. A simple counter in one browser tab models the decision; the server must create durable monotonically ordered versions for each case. A timestamp from a client device is not a reliable ordering key for concurrent server writes.
Implementation
let visibleVersion = 12;
function classifyUpdate(incomingVersion) {
if (incomingVersion <= visibleVersion) return "stale";
if (incomingVersion > visibleVersion + 1) return "refresh snapshot";
visibleVersion = incomingVersion;
return "apply";
}
console.log(classifyUpdate(14));
visibleVersion = 14; // Version obtained from the refreshed case snapshot.
console.log(classifyUpdate(13));
console.log(classifyUpdate(12));Observed output
refresh snapshot
stale
staleCost and boundaries
Comparing versions is O(1) per event. Keeping replay history costs O(E) storage for E retained events and requires an expiry policy. A gap-triggered snapshot fetch adds a network request, but avoids displaying a state assembled from missing changes. A busy stream should batch or coalesce status updates so DOM work does not overwhelm interaction. If the service cannot provide durable event history, document that reconnect always performs a fresh read rather than pretending every event will be replayed.
Common Mistakes
- Do not overwrite a newer status with a delayed old event.
- Do not use client wall-clock time as the authoritative sequence.
- Do not assume reconnect automatically replays every missed event.
Connected lessons
Media and Live Updates; Safe File Upload Pipeline; Image Variants and Delivery Budgets; Server-Sent Events or WebSocket for Live Views; Page loading: keep content available while CSS and scripts arrive; Fetch requests: separate HTTP failure, transport failure, and cancellation; HTML srcset and sizes: let the browser choose an appropriately sized image.
Failure trace
The browser displays version 14, then a delayed event for version 13 arrives from another worker and overwrites it. After reconnect, the stream begins at version 17; versions 15 and 16 were missed. Compare versions before applying an event, and fetch a complete snapshot on a gap unless the server can replay a durable sequence.
Verification
- Deliver versions 14, 13, and 15 out of order; the visible version must never move backward.
- Drop one event, reconnect, and confirm a snapshot or replay restores the current record.
- Reject an event for a different case even when its version number is higher.
Decision note
A timestamp is a weak ordering key when workers and client clocks differ. Use a server-owned sequence scoped to the record and document how long replay history is kept.
Apply and check
Build Project: live review board with ordered status; then check the boundary with Web Development: offline and delivery contracts quiz.
Further connections
Stream Cancellation and Partial-Result Contract.
Further connections
Snapshot, Delta Cursor, and Gap Recovery; Collaborative Conflicts and Presence Expiry.
Further connections
WebRTC Signaling, Room Authorization, and Offer Order.
Further connections
web-tech
web-development