bedrock-kv / bedrock / f334855498218f8fda603d83719b8ddae3081d61

82%

push

github

Carry bootstrap records that predate system_materializers (#207)

**P0 against `develop`.** Ticket: `bedrock-q67.21.21`. Regression from
`bedrock-q67.21.12` (#203, merged today).

Every cluster created before #203 is bricked by upgrading: recovery
never completes, and every client read hangs.

## Reproduced, variable isolated

| Bootstrap record | Result |
|---|---|
| Fresh cluster on `develop` | `RESULT: nil` — works |
| **Same cluster, same data, `system_materializers` stripped** |
`:bootstrap_names_no_system_materializers`, retried forever |

A user's real broken cluster decodes to exactly that:
`system_materializers: %{}`, `fresh?: false`, epoch 3, one log. Its
record was last written at 13:33 while the worker dirs were touched at
19:25 — recovery ran and never completed.

## Two defects, one assumption

Both from assuming a newly added field is always present.

**1. `resolve_system_materializer` treated "the record names nobody" as
unrecoverable.** The ticket said so outright — *"recovery cannot learn
where the metadata lives, and no retry will change that."* That is
wrong. The locking phase has already locked every advertised
materializer and each reports its own `shard_id`, so tag 0 can be **read
from evidence**. Reading evidence is not inventing a metadata store —
inventing is what `.12` actually forbids, and this does not do it.

**2. `build_updated_bootstrap` used `%{record | field: ...}`**, which
raises `badkey` for a key the map does not already have. A record
decoded from a FlatBuffer written before the field simply has no such
key, so the director crashed in a tight retry loop — on exactly the
clusters an upgrade must carry. `Map.merge` adds what is missing and
overwrites what is not, which is what "rewrite these fields" means.

## What does not change

A record that **does** name members, none of them available, still
stalls — **even with a healthy stranger locked and ready.** Substituting
a different worker is the fabrication FDB refus... (continued)

14 of 14 new or added lines in 2 files covered. (100.0%)

6731 of 8604 relevant lines covered (78.23%)

1039.93 hits per line