Decide what a cache written by another version, or half-written, is allowed to do

[iderex]

What this milestone writes outlives the process that wrote it and outlives the
version of the core that wrote it. Two cases follow from that and neither is
covered by #40, #42 or #43.

A core that has been upgraded meets bytes an older core wrote. If it reads them
as though it had written them itself, the failure is a misread field rather than
a missing file, so it shows a person the wrong thing instead of showing an error.

A write that did not finish. A device losing power, a process the platform killed
for using too much memory, and a storage implementation whose own write was
partial all leave an entry that exists and is not what it claims to be. On a
television the power case is the normal one.

The byte store in #40 belongs to the client, so the core cannot assume the write
was atomic. What it can do is refuse to believe an entry it cannot verify.

What this produces

A version stamped into whatever the core writes, and a stated rule for a stamp
that does not match. Discarding the entry is a legitimate answer and reading it
anyway is not, and whichever is chosen carries its reason.

A way to tell a complete entry from a truncated one that does not rely on the
storage implementation being atomic.

Recovery that is local and silent. An entry failing either check is dropped and
refetched on its own, rather than the whole cache being cleared because one entry
was bad, which turns a single truncated file into a cold start.

A named report through the diagnostics interface in #100 when entries are
dropped. A cache that quietly empties itself on every start is a performance
defect that presents as a slow network, and it can stay that way for a long time.

The same two rules considered against the offline queue in #47, where a dropped
entry is a person's action rather than a list that can be refetched. The rule
there may have to differ, and this issue says whether it does rather than leaving
the queue to inherit a rule written for something cheaper.

Done when

A test writes an entry carrying a previous version's stamp and proves the stated
rule. A test truncates an entry and proves it is dropped and refetched rather
than read. A test proves one bad entry does not take a good neighbour with it.
The queue case is answered in the same place, either way. Blocked on #40, #42
and #47.

[iderex]

The rule landed as docs/decisions/0105-an-entry-this-version-did-not-write.md, on 9931223.

Everything the core writes through the store in 0040 is wrapped in an envelope of its own: a format version, the kind of the payload, the payload's length and a digest over it. A read parses the envelope, checks the version, checks the length, checks the digest, in that order, and only then looks at the payload. Any of the four failing produces absence.

The envelope rather than a fifth store operation, and 0040 named that as a reversal condition, so it is worth saying the condition has not happened. A fifth operation would be the store telling the core whether a write completed, and it is not needed because the answer is derivable from what a read already returns.

A version that does not match discards the entry, in both directions, including one written by a newer build. This issue asked for the reason rather than the choice, and the reason is that the alternative has no stopping point: reading an older entry means the build carries every shape it has ever written, each tested against a fixture nobody can regenerate once the version that produced it is gone, and what actually gets built is a reader for the last shape and a hope about the ones before it. There is a neighbouring version already decided and the two are kept apart in the record: 0041's version tag sits inside the digest that forms the key, so a key construction change makes an old key space unreachable, while this one covers a change to what is stored under a key that is still reachable.

The length and the digest do different jobs. The length catches ordinary truncation cheaply and before anything is allocated. The digest catches the case the length misses, which is a write replaced in place by a shorter one that left the tail of the previous entry behind, so the bytes are the stated length and are two entries end to end.

What the digest does not buy is in the record rather than left to be assumed, because it is the sentence that would otherwise be quoted back as a property this repository has. It is not authentication. Anything that can write the store can write a matching digest, which is why 0101 treats those bytes as untrusted whatever the check returned. Parsing a payload whose digest matched is still parsing untrusted input.

A drop takes one entry and nothing else. Clearing the cache on a bad entry is refused by name: it turns one truncated file into the cold start #46 exists against, on the device that just lost power, and it is self-concealing, because the evidence goes with the cache. The drop is silent to the person and never silent to a report, as an event at notice through 0100 carrying the correlator from 0071 rather than the key, and as a standing count separated by which check failed, so that one drop after a power cut and four hundred drops on every start are different readings rather than the same one.

The queue case is answered here rather than left to inherit a rule written for something cheaper, which is what this issue's last condition asks for. The envelope is the same and three things differ. A dropped queue entry is reported at failure rather than notice and counts into the drop count 0047 already keeps, so a client reporting what was lost reports one number rather than two. The drain steps over a bad entry instead of stopping at it, because 0047 stops at the first entry that could not be delivered and a corrupt entry is not undelivered, it is gone, and waiting behind it strands every later action. A counter that fails its own envelope is rebuilt as one above the highest counter among the surviving entries, because the only property it has to hold is order among what is there, and emptying a queue to protect a number that can be recomputed from its own entries is the silent discard arriving as housekeeping.

Which digest function and which width are not fixed, for the same reason 0041 does not fix them: that follows the toolchain in #11, and the record states the requirement rather than naming a function that does not exist yet.

Of the four conditions here, one is met and three are untouched. The queue case is answered in the same place, either way, and it is answered the other way with its reasons. Writing an entry carrying a previous version's stamp, truncating an entry, and proving one bad entry does not take a good neighbour with it are statements about running code, and there is no language chosen, no build and no test command in this tree. This stays open on all three.