bedrock-kv / bedrock / 780bd9f63bf8c1eeb6e633ad2aac95a94c1e7eed

82%

push

github

In-band retirement: the victim learns from its own stream (#206)

Ticket: `bedrock-q67.21.6` — the **last open child** of
`bedrock-q67.21`. Based directly on `develop`.

## Why

Healing and adoption introduce mid-epoch membership changes, so a
materializer whose assignment is withdrawn must learn *now*. Until this,
the only trigger was `{:tsl_updated, ...}` — broadcast solely on
recovery completion. Retirement latency was unbounded, and three live
comments already promised in-band behaviour that did not exist.

## Mechanism: FDB's privatization

Re-verified against the tree at `afeef452b`:

| Claim | Citation |
|---|---|
| Proxy privatizes with `withPrefix(systemKeys.begin)`, then
`toCommit->addTag(tag)` and `writeMutation(privatized)` |
`ApplyMetadataMutation.cpp:291-317` |
| Storage diverts on the prefix to `applyPrivateData`, before any normal
application | `storageserver.actor.cpp:11444-11450` |
| The predicate is "is this about me?" — `startsWith(data->sk)` |
`storageserver.actor.cpp:11523` |

*(The ticket cited `11571-11601` for the recognizer; that range is the
rollback branch **inside** `applyPrivateData`. Claims were right, line
numbers weren't — corrected here and in the ticket.)*

**Producer.** The commit proxy emits a second copy of a committed
membership `CLEAR`, prefixed past `end_of_keyspace/0` and addressed to
the shard tag **the key itself carries** — an explicit tag, not a
boundary walk, since `split_mutation_by_shards/2` finds no shard for a
key past every boundary and would fail the batch.

The prefix does two jobs. It moves the key outside every shard's range
so no materializer can store it, and it makes the notice
**unforgeable**: ingress already rejects that range in *both* modes, so
only the proxy, synthesizing after validation, can produce one.

**Consumer.** The victim recognizes it at the single point where stream
data becomes durable state, and stops rather than applies. The predicate
is FDB's own, collapsed by the set-valu... (continued)

19 of 22 new or added lines in 4 files covered. (86.36%)

6786 of 8672 relevant lines covered (78.25%)

1030.34 hits per line