From the M1 arming interlock final review (PR #193).
Gap: RtbhManager::rehydrate, FlowSpecManager::rehydrate, and XdpManager::reapply_active re-announce persisted active state on a fresh session by calling the BGP/map executor directly, bypassing execute_and_journal_announce and therefore the C2 confirm-before-active rollback. resume()/mark_resumed has already inserted the entry, so a failed re-announce logs a warning and continues, leaving a phantom "active" entry the control plane believes is mitigated — the same class C2 fixes, in the boot-time path.
Scope: armed-restart-only (rehydrate is skipped under shadow). Not a regression — pre-M1 rehydrate had identical behavior. Low probability (bgp.announce is an mpsc send that succeeds even before the session is Established; the session task re-announces on establishment), so it requires the session task/channel to be gone precisely during startup rehydrate.
Design note: rehydrate deliberately upholds a competing invariant ("never silently drop a persisted row"), so the fix is a genuine decision — route re-applies through a confirm-or-retry path (rollback + retry, or a pending-reapply queue) rather than the current keep-and-warn. Don't let the C2 docs claim boot-path coverage until this lands.
Also from the same review (smaller):
- Duplicate
DISARMED WARN log (main.rs task arm + disarm() itself).
- Disarm withdraw-error tolerance tested only on RTBH, not FlowSpec/XDP (structurally identical).
From the M1 arming interlock final review (PR #193).
Gap:
RtbhManager::rehydrate,FlowSpecManager::rehydrate, andXdpManager::reapply_activere-announce persisted active state on a fresh session by calling the BGP/map executor directly, bypassingexecute_and_journal_announceand therefore the C2 confirm-before-active rollback.resume()/mark_resumedhas already inserted the entry, so a failed re-announce logs a warning and continues, leaving a phantom "active" entry the control plane believes is mitigated — the same class C2 fixes, in the boot-time path.Scope: armed-restart-only (rehydrate is skipped under
shadow). Not a regression — pre-M1 rehydrate had identical behavior. Low probability (bgp.announceis an mpsc send that succeeds even before the session is Established; the session task re-announces on establishment), so it requires the session task/channel to be gone precisely during startup rehydrate.Design note:
rehydratedeliberately upholds a competing invariant ("never silently drop a persisted row"), so the fix is a genuine decision — route re-applies through a confirm-or-retry path (rollback + retry, or a pending-reapply queue) rather than the current keep-and-warn. Don't let the C2 docs claim boot-path coverage until this lands.Also from the same review (smaller):
DISARMEDWARN log (main.rs task arm +disarm()itself).