oprf-gate-2of3: add leg D (retry-then-success convergence)#96
Conversation
Signed-off-by: Kyle 🐆 <kyle@privkey.io>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughThe OPRF gate test increases its boot-unlock retry timeout, adds a retry-then-success scenario with delayed holder availability, and updates the fail-closed scenario to stop the new holder service before rebooting. ChangesOPRF retry validation
Estimated code review effort: 2 (Simple) | ~10 minutes Sequence Diagram(s)sequenceDiagram
participant TestBox
participant FrostGate
participant HolderService
participant Vault
TestBox->>FrostGate: reboot with holders unavailable
FrostGate->>FrostGate: enter activating retry state
TestBox->>FrostGate: verify vault remains locked
TestBox->>HolderService: start one holder service
FrostGate->>HolderService: retry unlock request
HolderService-->>FrostGate: holder response
FrostGate->>Vault: unlock and mount vault
Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
What
Add leg D to the
oprf-gate-2of3boot test: the box boots with both holders down (so the gate's first discovery attempt fails insufficient-peers), a holder then comes online mid-retry, and a later attempt converges to a mounted, serving vault.Also raises the test's
bootUnlockTimeoutSecfrom 45s to 100s so leg D has room to converge after a proven-failed first attempt, while leg C still fails closed well within its 180s wait.Why
The test covered retry-then-fail-closed (leg C) and first-attempt unlock (legs A/B, holders pre-started), but never retry-then-success — a boot that fails an initial insufficient-peers attempt and converges once a holder appears. This is the real recovery path when a holder is slow to come up at boot (e.g. a geo-distributed holder), and it complements the in-attempt holder failover added in keep v0.7.4.
Deterministic by construction (not a race)
The bead was deferred because naively bringing a holder up races its startup against the gate deadline. This leg avoids the race:
ActiveState=activating).gate_unlocked_boot()(gate goesactive, vault mounted, Vaultwarden up).Verification
Ran the full 4-VM test locally: passed (987s), all legs A-D green, on the first run (the determinism holds).
Closes keep-node-asf.
Summary by CodeRabbit