bedrock-kv / bedrock / 04d7fff83a5ae9823e212fc21154639d3a7a5498

82%

push

github

Migrate the pre-q67.21.9 single-valued materializer family (lost from #207) (#208)

**P0, and it is the commit #207 lost.** Ticket: `bedrock-q67.21.21`.

#207 merged at 00:53 UTC and **does not contain this fix.** The merge
deleted the branch; my push of this commit recreated it afterwards, so
it was never part of the PR. `git merge-base --is-ancestor 63937984
origin/develop` → false. The push output said `[new branch]` and I did
not read it.

That is exactly why the reported cluster still loops after merging,
pulling and rebuilding: it has the bootstrap fix (so it logs *"adopting
sole locked survivor"*) but not this one, so it stalls on the family
read — an `[error]` line that a default livebook log level filters out.

## The defect

`.9` changed the membership family from `materializers/<tag>` → packed
`{worker_id, node}` to `materializers/<tag>/<worker_id>` → node. The
reader was written to fail loudly on the old shape:

```
{:invalid_materializer_entry, "\xff/system/materializers/0"}
```

Its docstring calls that *"deliberately the loud edge of the format
change."* Right as a **guard** — reading the old family as *empty* would
re-recruit every shard and orphan the live ones. Wrong as the **only**
behaviour: it stalls every recovery on every pre-`.9` cluster, forever.

The old value packs `{worker_id, node}`, which is one member of the same
set. So it folds in, and both shapes may coexist mid-migration. Still
hard-fails: a foreign key, or either shape with an undecodable value.

## Folding alone would not have been enough

It would leave the family in two shapes permanently, and a legacy member
could then **never be retired** — retirement clears the new-shape key it
does not have. So recovery finishes the job: every member the legacy key
held is rewritten in the set-valued shape, and only then is the legacy
key cleared, both in **one** transaction so no reader sees the tag
unrepresented.

Rewriting *every* member matters: the legacy key may name a ... (continued)

31 of 36 new or added lines in 5 files covered. (86.11%)

6755 of 8631 relevant lines covered (78.26%)

1037.25 hits per line