Queue what a person did while the server was gone, and reconcile it on return

[iderex]

Somebody marks something watched on a train. Either that is remembered or it is
not, and if it is not, then the offline behaviour was decoration. This queue is
also what the playback positions in M6 ride on, so it is built once here.

What this produces

A durable queue of actions taken while the server was unreachable, surviving a
restart, since a train journey usually includes closing the application.

An ordering rule and a rule for two actions that touch the same thing, because
the last one usually wins and the record says so explicitly rather than leaving
it to the order the queue happened to drain in.

Delivery that is safe to repeat, so that an action sent twice after a flaky
reconnection does not count twice.

A bound on the queue, and a stated rule for what happens when it is full, which
is a real case on a device left offline for a month.

A named report of what could not be delivered, since silently discarding a
person's action is the failure this whole issue exists to prevent.

Done when

A test queues actions offline, restarts the core, restores the server and
proves every action arrived exactly once and in the stated order. A test fills
the queue past its bound and proves the stated rule. Blocked on #40, #45, and
#102 for the clock a queued action's wait is measured against. What a
half-written queue entry may do is #105 rather than this issue.

[iderex]

The clock this issue was waiting on is decided in docs/decisions/0102-the-clocks-every-deadline-is-measured-against.md.

A queued action's wait is on the elapsed clock, which is the row the record names for it. The wait is real time and continues while the device sleeps, so a journey that includes the application being suspended does not shorten how long an action has been waiting, and a device that slept past a delivery point owes the attempt on waking rather than restarting the wait.

The steady clock is wrong for the same reason it is right for a request timeout. A suspension takes a request away and leaves nothing to time out, and it does not take away the fact that somebody's action has been sitting undelivered.

One case the record does not close, and it belongs here rather than there. Both monotonic clocks reset when the process ends, and this queue is durable across a restart, so a wait that has to survive one is the shape the record says none of the three clocks answers. Its answer for that shape is to anchor on something outside the device rather than to reach for a fourth clock, which is what it does for a cache entry's age. What a restored entry's wait is anchored on, and whether the bound on the queue is read against that anchor or against the elapsed clock from the moment of restore, is part of the ordering rule this issue owns. A restored queue that treats every entry as freshly enqueued is the failure worth naming: it is silent, it moves nothing, and it is indistinguishable from a queue that is simply patient.

[iderex]

The queue landed as docs/decisions/0047-the-write-queue.md, on bcd0744. The clock this issue was waiting on is settled in the comment above and the record reads it rather than restating it.

It is the write path rather than the offline path. Every write goes onto the queue whether the server is answering or not, and one made while the server is there is drained immediately. #57 already required that of progress reports, on the grounds that the offline case then needs no separate path and cannot be forgotten, and the record makes it the rule for every write. Two paths would agree until they did not, and the disagreement would be reachable only on a device whose connectivity changed mid-write.

The five things this issue asks for are answered as follows.

Order is a counter stored with the queue and increased once per entry, not a timestamp. A counter because the order of somebody's own actions must not be disturbed by a clock correction, a suspension or a restart, and 0102 already says the wall clock moves in both directions and both monotonic clocks reset. Draining is in counter order and stops at the first entry that could not be delivered, because continuing past it would deliver a later action ahead of an earlier one for a different target.

Two actions touching the same thing are one entry, with the later replacing the earlier in place and keeping the earlier one's position in the order. The coalescing happens at enqueue rather than at drain, and that is the decision rather than a detail: at drain, the queue holds all ninety positions somebody produced while scrubbing, so the bound is reached by activity rather than by breadth and the person it punishes is the one who used the application most. It is per kind as well as per target, since a position and a watched mark are two statements about one item and neither replaces the other.

Delivery is safe to repeat by construction rather than by bookkeeping. Every queued action is an assertion of a desired state, never a delta, so a delivery that reached the server and whose acknowledgement did not reach the device can be sent again with no second effect. An action that cannot be expressed that way is not queued at all: it is attempted when it is asked for and it fails with a kind from 0004 when the server is absent. That is a loss of function stated in the open rather than a queue that quietly counts something twice.

The bound is one thousand entries per session, chosen rather than measured, and what makes it defensible is the coalescing rule, since a thousand entries is a thousand distinct items somebody touched rather than a thousand actions. At the bound a new entry displaces the oldest, because the alternative refuses to record what somebody just did while holding something from three weeks ago. The harness in #65 is where a measured replacement would come from.

A drop is reported twice over, because silently discarding a person's action is what this issue exists to prevent. As an event through 0100 at the moment it happens, carrying the correlator for the target under 0071 rather than the identifier, and as a standing count the queue keeps per session and a client can read afterwards through a call that cannot wait.

The case the comment above leaves open is answered here rather than being left to be discovered. A restored entry's age is anchored the way 0043 anchors a cache entry's, with two moments stored at enqueue, on 0102's anchor and with its two guards. That age is carried for reporting and never acts: it is not a reason to drop an entry, not an input to the bound, and not a threshold. An action somebody took is not less true because their device was off, and expiring one would be the silent discard arriving in the shape of housekeeping. The wait 0102 puts on the elapsed clock is a different quantity, it is the interval between attempts inside one run, it resets with the process, and on a restore the core attempts delivery when the server is next known reachable rather than resuming a wait.

Both conditions here are untouched. Queueing actions offline, restarting the core, restoring the server and proving every action arrived exactly once and in the stated order, and filling the queue past its bound to prove the stated rule, are statements about running code. There is no language chosen, no build and no test command in this tree, and #21 is open. This stays open on both.