Add WAL recovery plan object#623
Conversation
|
Warning Review limit reached
More reviews will be available in 2 minutes and 37 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more credits in the billing tab to continue. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (6)
✨ 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 |
Code Lawyer update
Local validation before opening:
|
github-project-automation
Bot
moved this from Todo
to Done
in Continuum Stack Convergence
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 543d3a13e5
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
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".
| let obstruction_count = | ||
| len_u64(retained_material_obstructions(index, available_material).len()); |
There was a problem hiding this comment.
When a recovered WAL has only missing or corrupt RetainedMaterialKind::Diagnostic material, retained_material_obstructions returns a DiagnosticLoss scope; the existing doctor path filters that scope because diagnostic loss does not block causal recovery. This new posture uses the unfiltered obstruction count, so the recovery plan reports Obstructed even though all recovery-required material is available, creating false obstruction evidence for diagnostic-only loss.
Useful? React with 👍 / 👎.
| availability: if obstruction_count == 0 { | ||
| WalRecoveryRetainedMaterialAvailability::Available | ||
| } else { | ||
| WalRecoveryRetainedMaterialAvailability::Obstructed | ||
| }, |
There was a problem hiding this comment.
When the WAL contains a ReadingEnvelopeRetained record whose ReadingRefRecord.posture is Missing, Corrupt, or Obstructed (or whose payload/envelope digest has no matching retained-material record), retained_material_obstructions still returns zero because it only walks material_by_digest. The plan then reports Available even with unrecoverable reading evidence, hiding the app-safe missing-retention posture during recovery planning.
Useful? React with 👍 / 👎.
| Self { | ||
| bootstrap_source, | ||
| checkpoint_posture, | ||
| replay_suffix: WalRecoveryReplaySuffix::from_report(report), |
There was a problem hiding this comment.
When checkpoint_posture is Selected, recovery is supposed to use the checkpoint as the base and replay only the WAL tail after that checkpoint, but this always derives the suffix from the full scan report. A plan for a checkpointed recovery will therefore report the WAL's first committed LSN and all committed transactions, including history already covered by the checkpoint, which makes the recorded replay evidence inaccurate for checkpoint-backed recovery.
Useful? React with 👍 / 👎.
1 participant
Closes #574
Summary
WalRecoveryPlanand related posture records for recovery bootstrap source, checkpoint selection, replay suffix, tail posture, recovered index roots, retained-material posture, and projected evidence posture.WalRootor storageWalManifestwithout requiring graph WAL nodes as input.recovery_plan_bootstraps_from_wal_rootand include the exact witness incargo xtask test-slice durability-release.Validation
cargo fmt --checkcargo test -p warp-core --test causal_wal_tests recovery_plan_bootstraps_from_wal_rootcargo clippy -p warp-core --test causal_wal_tests -- -D warningscargo test -p xtask test_slice_durability_release_stays_explicitnpx markdownlint-cli2 CHANGELOG.md docs/topics/WAL.md docs/workflows.mdgit diff --checkcargo test -p warp-core --test causal_wal_testscargo clippy -p warp-core --lib,cargo check -p warp-core, markdownlintcargo fmt --all -- --check,cargo check -p warp-core --quiet,cargo test -p warp-core --test causal_wal_tests, Prettier markdown checkTest speed note
cargo test -p warp-core --test causal_wal_tests recovery_plan_bootstraps_from_wal_rootwitness instead of Cargo's package-level name filter.