Repository navigation
fix(wedding-db): correct pre-loss recovery witness - #3742
Conversation
|
@coderabbitai full review |
|
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Warning Review limit reachedNext included review available in 57 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Repository YAML (base), Organization UI (inherited) Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (2)
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 |
|
Codex Review: Didn't find any major issues. More of your lovely PRs please. Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
The first Wedding database recovery run refused before its first database command because the pinned Flux reconciliation digest had one mistyped hex character. The live history records
ba344a9c; the recovery guard expectedba344e9c.This corrects the exact pre-loss witness, covers it with a regression test, and reports only an allow-listed phase name when a trusted recovery run refuses. Untrusted invocations still receive the generic message and no subprocess details.
Validation:
node --test tests/wedding-db-incident-recovery/recovery.test.mjsgit diff --checkSELECT pg_switch_wal()2026-09-09T01:57:41Z, successful reconciliation, exact digest, and exact origin revisionThe failed run created no backup, recovery cluster, PVC, network policy, proof ConfigMap, or staging schema. Its cleanup job succeeded, so retrying after this change is deployed starts from the original fenced state.