Offline actions queue and flush when the network returns
Aliases: pending queue · flush on reconnect · outbox
What it is
People still write, like, and mark-read while offline. Those acts must neither be painted as already on the server nor dropped. They enter an offline action queue and are processed in order once the link returns. The queue is state, not a log: every item still owes a real write, and the interface must be able to answer “how many are waiting, whose turn is it”.
This leaf is the seam of “accept now, deliver later”. Whether the local copy is the authoritative replica, and how conflicts merge, are a different architecture. Without a queue, writable-offline is input swallowed into a vacuum.
Why it happens
A dropped link splits one write into two: the device accepts intent, the far side honours intent. Between them a durable container has to exist, or a killed process, a user leaving, a memory reclaim evaporates the intent. The container is ordered: a comment written first must not be overtaken by a later “delete this post”, or the world after restore will not match the user’s story.
Restore is not automatic success. As the queue drains, each item can be refused (permission moved, object gone, quota full). “Process” therefore includes confirm, fail, and retry — the queue is not an incinerator. If the UI only flashes “syncing” on restore and then empties the list, no one can audit whether what was owed was honoured. Until it is empty, the queue must be queryable.
Where it stops holding
Purely local objects (an unshared draft, a list that lives only on this device) need no outbound queue; a disk write is the honouring. Read-only offline has nothing to enqueue. Payments, outbound mail, irrevocable submits should not enter this “handle later” queue — they belong outside the offline scope, not pretended-accepted. A queue that grew for a week of travel drains as a conflict storm; that wants a restore preview, not a silent replay, and is a long-offline problem, not solved by making the queue larger. If restore also pours a flood of downlink updates, the drain must be given a path, or uplink intent is overwritten and queuing was theatre.
Applying it
- Every offline write enters a durable queue. Kill the process and reopen: the queue is still there.
- Each item has a visible identity: pending, sending, failed. On restore, process in original order. Failed items stay put rather than vanish.
- Give the queue a door: at least a count and the failures. Do not only write “syncing” in the chrome.
- How to check: offline, write two comments and change a title, force-quit, reopen. Both comments and the title edit should still be there, marked pending. On reconnect they should become delivered in order; if the second is made to fail, the first must still succeed and the second must remain failed and retryable — not all three evaporating together.