HeldRecords is BTreeMap<[u8; 16], HeldRecord> (crates/engine/src/net/liveness.rs), keyed by node id. PR #1298 had to carry the vault settings record — which has no node id — in a separate Engine::settings_record cell, because a synthetic [u8; 16] key would sit in a slot a resolved record can claim and evict.
That was the right call for that PR: re-keying the map touches crates/engine/src/net/resolve.rs and crates/engine/src/sync/drain.rs, both of which were owned by other in-flight PRs.
The cost is that the renewal set is now two places, and every consumer has to know both. The vault pointer record is name-keyed too and is the next obvious candidate for session-held renewal, which would make it three.
What to do
Re-key HeldRecords on a key that admits both shapes — either the record's own routingKey, which every HeldRecord already carries and which is what the re-PUT actually uses, or an enum (Node([u8; 16]) | VaultSettings | …). Fold Engine::settings_record back into the one map and delete the parallel clear/clone/chain sites in crates/engine/src/facade.rs.
Note the freshness invariant that goes with it: the resolve tick replaces each held record in place, which is what keeps the renewal off a stale record. The settings slot has no such refresher, so PR #1298 added live_settings_record to prove the held record is still the live one before a pass renews it. Whatever key this lands on, that check has to survive the move — a renewal re-signs at floor + 1 with a fresh validity, so re-signing a superseded body rolls the account back to it.
Part of #655
HeldRecordsisBTreeMap<[u8; 16], HeldRecord>(crates/engine/src/net/liveness.rs), keyed by node id. PR #1298 had to carry the vault settings record — which has no node id — in a separateEngine::settings_recordcell, because a synthetic[u8; 16]key would sit in a slot a resolved record can claim and evict.That was the right call for that PR: re-keying the map touches
crates/engine/src/net/resolve.rsandcrates/engine/src/sync/drain.rs, both of which were owned by other in-flight PRs.The cost is that the renewal set is now two places, and every consumer has to know both. The vault pointer record is name-keyed too and is the next obvious candidate for session-held renewal, which would make it three.
What to do
Re-key
HeldRecordson a key that admits both shapes — either the record's ownroutingKey, which everyHeldRecordalready carries and which is what the re-PUT actually uses, or an enum (Node([u8; 16]) | VaultSettings | …). FoldEngine::settings_recordback into the one map and delete the parallel clear/clone/chain sites incrates/engine/src/facade.rs.Note the freshness invariant that goes with it: the resolve tick replaces each held record in place, which is what keeps the renewal off a stale record. The settings slot has no such refresher, so PR #1298 added
live_settings_recordto prove the held record is still the live one before a pass renews it. Whatever key this lands on, that check has to survive the move — a renewal re-signs atfloor + 1with a fresh validity, so re-signing a superseded body rolls the account back to it.Part of #655