test(persistence): fix crash_recovery_graph_durability g1-g3 WAL v2 flat-file probe (task #31)#324
Conversation
…lat-file probe (task #31) The G1-G3 legacy-mode graph crash tests never reached their kill -9 scenario: wait_for_wal_bytes and G3's replay-idempotency length check still polled the flat <dir>/shard-0.wal WAL v2 layout, deleted in PR #236 one day before this test file was added (#237). The probe timed out after 20s waiting for a file that is never created — on every platform (Linux VM reproduces identically; not a macOS durability gap) — masked because the suite is #[ignore]d and no CI job runs it with --ignored. Both helpers now scan the real <dir>/shard-0/wal-v3/*.wal segment directory. The new wal_dir_total_bytes helper for G3 excludes each segment's fixed 64-byte WAL_V3_HEADER_SIZE so the fresh active segment each boot opens isn't misread as replay-time double-append. The underlying replay_graph_wal RESP-parse bug these tests expose (graph plane silently dropped on legacy-mode restart) was fixed separately in PR #322 (task #60); this harness fix is what lets g1-g3 prove it. Verification: g1-g5 green 3x consecutively on macOS (release-fast, MOON_BIN pinned to fresh binary per the stale-target/release trap); agent run additionally verified 5/5 on the Linux dev VM. fmt clean. Refs: task #31, PR #236, PR #237, PR #322 author: Tin Dang
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
|
Warning Review limit reached
Next review available in: 18 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?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 reviews. How do review 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 refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
✨ 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 |
…(v0.7.0 prep) Owner reconciliation 2026-07-14 of docs/PRODUCTION-CONTRACT.md against the tree (main is 67 commits past the v0.6.0 tag, carrying the full v0.6.1 hygiene scope and the v0.7 replication workstreams untagged): Re-ticked with verified evidence: - FUZZ-01: graph_props_record.rs restored, all 12 declared targets exist - ACL-REG-01: TXN/WS/MQ/TEMPORAL/CDC in metadata.rs + monoio intercept reorder (PR #258) - COLD-TTL-01: ColdIndex::sweep_expired + info_reclamation counters - SEC-07: SECURITY.md now states a release-agnostic supported-versions policy (latest minor line pre-1.0, LTS from v1.0.0) Updated honestly: - FT-PARITY-01: FT.AGGREGATE shipped (ft_aggregate.rs); FT.ALTER still absent -- stays unticked - CRASH-01: caveats recorded -- graph-durability g1-g3 never actually ran before PRs #322/#324 (WAL v2 flat-file probe + legacy replay no-op); crash_recovery_disk_offload_no_aof residual red (task #44) - SUPPLY-01: supply-chain.yml workflow in flight (task #63), tick on merge New rows for shipped-but-previously-untracked guarantees: - CRASH-02: 37-cell cross-plane kill-9 matrix (v0.8 G1, PR #298 + the 4 RED-group fixes #52/#53/#57/#60) - MEM-10X-01: 10x RAM datasets G2 acceptance (restart readiness 157s->3.7s, PRs #319/#297/#320) - REPL-PLANES-01: all-plane replication (Waves A/B, PRs #285/#294) - REPL-SOAK-01 (unticked): 24h replication soak gates the v0.7.0 tag Header refreshed (milestone = v0.7.0 Replication GA, tag gated on soak). scripts/check-production-contract.sh parses all new rows; GA-blocking gap is now an honest 17 rows. Refs: tasks #61-#65 author: Tin Dang
…(v0.7.0 prep) (#325) Owner reconciliation 2026-07-14 of docs/PRODUCTION-CONTRACT.md against the tree (main is 67 commits past the v0.6.0 tag, carrying the full v0.6.1 hygiene scope and the v0.7 replication workstreams untagged): Re-ticked with verified evidence: - FUZZ-01: graph_props_record.rs restored, all 12 declared targets exist - ACL-REG-01: TXN/WS/MQ/TEMPORAL/CDC in metadata.rs + monoio intercept reorder (PR #258) - COLD-TTL-01: ColdIndex::sweep_expired + info_reclamation counters - SEC-07: SECURITY.md now states a release-agnostic supported-versions policy (latest minor line pre-1.0, LTS from v1.0.0) Updated honestly: - FT-PARITY-01: FT.AGGREGATE shipped (ft_aggregate.rs); FT.ALTER still absent -- stays unticked - CRASH-01: caveats recorded -- graph-durability g1-g3 never actually ran before PRs #322/#324 (WAL v2 flat-file probe + legacy replay no-op); crash_recovery_disk_offload_no_aof residual red (task #44) - SUPPLY-01: supply-chain.yml workflow in flight (task #63), tick on merge New rows for shipped-but-previously-untracked guarantees: - CRASH-02: 37-cell cross-plane kill-9 matrix (v0.8 G1, PR #298 + the 4 RED-group fixes #52/#53/#57/#60) - MEM-10X-01: 10x RAM datasets G2 acceptance (restart readiness 157s->3.7s, PRs #319/#297/#320) - REPL-PLANES-01: all-plane replication (Waves A/B, PRs #285/#294) - REPL-SOAK-01 (unticked): 24h replication soak gates the v0.7.0 tag Header refreshed (milestone = v0.7.0 Replication GA, tag gated on soak). scripts/check-production-contract.sh parses all new rows; GA-blocking gap is now an honest 17 rows. Refs: tasks #61-#65 author: Tin Dang Co-authored-by: Tin Dang <tindang.ht97@gmail.com>
2 participants
Summary
wait_for_wal_bytes+ G3's replay-idempotency length check still polled the flatshard-0.walWAL v2 file, deleted in refactor(persistence)!: remove WAL v2 — WAL v3 only, XactCommit unified, AOF-authority recovery #236 one day before this test file landed (feat(graph): wave-2 engine improvements (W2-1..W2-14) + P0 v3 graph-durability fix, GCP-hardened #237). The probe timed out on every platform (Linux VM reproduces identically — not a macOS durability gap), masked because the suite is#[ignore]d.shard-<N>/wal-v3/*.walsegment directory; the G3 length helper excludes each segment's fixed 64-byte header so per-boot segment rotation isn't misread as replay double-append.replay_graph_walRESP-parse bug these tests expose was fixed separately in fix(persistence): legacy-mode graph WAL replay dropped raw RESP payload as cmd name (task #60) #322 (task feat(commands): list/hash/set convenience variants (LPUSHX/RPUSHX/LMPOP/HRANDFIELD/SMOVE/SINTERCARD) #60); this harness fix is what lets g1–g3 prove it.Verification
MOON_BINpinned to a fresh binary — the staletarget/release/moonfallback reproduces the old failure).cargo fmt --checkclean; test-only change (no src/).Closes task #31.