Skip to content
AITroveRead. Build. Understand.
Make this comfortable

Project: multi-tab offline case review

Last updated: 5 Oct 20268 min read
project
IntermediateBy AITrove Editorial

Build a case-47 review workspace used in two tabs and one intermittently connected device. Tab A saves version 7 while Tab B holds an unsaved note based on version 6. A same-origin message gives Tab B an invalidation hint, not the new private record; Tab B fetches a current authorized snapshot without overwriting its note. An offline status change enters a bounded outbox as operation op-47 and remains Queued until server acceptance. A lost response causes replay with the same idempotency key. A stale version becomes Conflicted and retains the local intent. The live queue starts from a snapshot tied to a server cursor, applies deduplicated deltas, and fetches a new snapshot on a gap or expired replay window. Editing presence expires after missing heartbeats and never grants a lock.

Build contract

  • Send scoped cross-tab invalidation hints, revalidate on focus after missed messages, and keep unsaved fields separate from fetched server state.
  • Persist a bounded account-scoped outbox with stable operation IDs, version preconditions, retry limits, and distinct accepted, conflicted, and rejected outcomes.
  • Bridge snapshot to change stream through a server cursor; detect duplicate, gap, expiry, filter change, and account change.
  • Test expiring presence separately from server write versions and expose a same-field conflict repair view.

Implementation checkpoint

javascript
function outboxState(responseStatus) {
  if (responseStatus === 412) return "conflicted";
  if (responseStatus === 403) return "rejected";
  return responseStatus >= 200 && responseStatus < 300 ? "accepted" : "retry-later";
}
console.log(outboxState(412));
// Output: conflicted

Cost and boundaries

The outbox and retained case snapshots use O(n) device storage for n pending or cached records; cap both item count and total bytes, and plan for browser eviction. Snapshot refresh costs O(m) transfer for m records, while a valid delta stream costs O(d) for d changes since the cursor. Presence heartbeats create traffic proportional to active editors and can expand sharply if every update is broadcast to every participant. Cross-tab hints are cheap but can trigger duplicate fetches across many tabs; coalesce repeated versions. Measure stale-window duration, replay age, duplicate suppression, gap recovery time, and the number of unsaved edits retained through a conflict.

Failure drill

Save in Tab A while Tab B has unsaved text. A direct broadcast of the whole case must not replace Tab B’s note. Close Tab B before the next change; reopening it must revalidate without receiving the missed message. Lose the server response after a committed write and verify replay makes one audit entry. Cause a 412 and ensure the edit does not claim Saved. Omit a delta sequence and require a fresh snapshot rather than a silently stale queue. Put one editor to sleep; presence must expire without blocking another editor. Move the device clock and confirm it cannot win a server version conflict.

Acceptance checks

  • Unsaved local text survives cross-tab invalidation and a version conflict.
  • A replayed offline operation creates at most one server mutation.
  • An expired or mismatched cursor triggers a fresh scoped snapshot.
  • Presence expires without acting as an edit lock or authorization grant.

Common Mistakes

  • Assuming a browser channel is a durable message queue.
  • Creating a new idempotency key after a lost response.
  • Keeping a delta cursor across a filter or account change.
  • Treating presence or client timestamps as the write authority.

Related lessons

Cross-Tab Invalidation and Version Checks; Offline Outbox, Idempotency, and Replay; Snapshot, Delta Cursor, and Gap Recovery; Collaborative Conflicts and Presence Expiry; Conditional Writes and Lost-Update Prevention.

web-tech
web-development
Storage details