feat(warp-core): add filesystem runtime WAL ack path#597
Conversation
|
Warning Review limit reached
More reviews will be available in 10 minutes and 43 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 refill rate. 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, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly. 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 |
![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: 047656bdef
ℹ️ 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".
|
@codex Activity Summary for review-fix commit
Validation repeated locally:
|
github-project-automation
Bot
moved this from In Progress
to Done
in Continuum Stack Convergence
There was a problem hiding this comment.
💡 Codex Review
echo/crates/warp-core/src/trusted_runtime_host.rs
Lines 1199 to 1201 in 94d5221
Check WAL acceptance before appending after recovery
After a process restart over an existing filesystem WAL, the fresh in-memory runtime has no duplicate-submission index, so submit_app_intent returns duplicate == false for the same envelope even though the WAL already contains the durable acceptance. Because the durable idempotency check is gated on handle.duplicate, a client retry after an ACK/crash appends another SubmissionIntake transaction for the same submission instead of returning from recovered WAL evidence. The WAL acceptance check needs to run for the derived handle before appending, not only when the volatile runtime noticed the duplicate.
ℹ️ 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".
| ) -> Hash { | ||
| let mut hasher = blake3::Hasher::new(); | ||
| hasher.update(TRUSTED_RUNTIME_WAL_DOMAIN); | ||
| hasher.update(b"runtime-state-frontier:recovered"); |
There was a problem hiding this comment.
When a filesystem WAL is reopened after any committed scheduler tick, TrustedRuntimeWalCursor::from_recovery rebuilds the runtime-state cursor through this helper, but the helper uses a different domain and a reduced input set from runtime_state_frontier_digest used when the tick was originally committed. Any ticks appended after recovery therefore branch from a synthetic frontier rather than the previous tick's committed after_digest, and subsequent recoveries will keep deriving a different chain than the one committed before restart. This makes post-restart scheduler-tick WAL evidence unreplayable/unauditable; persist enough tick correlation data to recompute the original digest, or make the original commit use the recoverable digest law.
Useful? React with 👍 / 👎.
| next_lsn, | ||
| } = config; | ||
| let TrustedRuntimeWalConfig { store, next_lsn } = config; | ||
| let mut store = TrustedRuntimeWalStore::open(store)?; |
There was a problem hiding this comment.
If two trusted hosts are configured against the same filesystem root before either one appends, each call opens an independent store and recovers the same writer cursor, but no filesystem lock or lease is acquired before the adapters are returned. Both adapters can then build and append transactions starting at the same next_lsn, leaving duplicate LSNs in the segment and making later recovery fail continuity validation. The filesystem-backed runtime WAL should reject or serialize a second writer for the same root before exposing an appendable adapter.
Useful? React with 👍 / 👎.
| fn read_commits(&self) -> Vec<WalTransactionCommit> { | ||
| match self { | ||
| Self::InMemory(store) => store.read_commits(), | ||
| Self::Filesystem(store) => store.read_commits(), |
There was a problem hiding this comment.
For filesystem-backed adapters, this delegates to FilesystemWalStore::read_commits, which returns an empty vector on any segment read/decode error. That means host evidence helpers such as commits(), submission_acceptance_count(), and scheduler_tick_count() can report a corrupt WAL as having zero committed history even though recover_read_only() correctly surfaces the corruption. These inspection paths should return an error or share the recovery scan so corrupt filesystem history is not indistinguishable from an empty root.
Useful? React with 👍 / 👎.
1 participant
Summary
TrustedRuntimeWalConfig::filesystem(...)andTrustedRuntimeWalStoreKind::Filesystemfor host-owned filesystem runtime WAL rootsFilesystemWalStorewhile keepingTrustedRuntimeApplimited to submit/observe surfacesCloses #555
Validation
cargo test -p warp-core --features "native_rule_bootstrap trusted_runtime host_test" --test trusted_runtime_host_loop_tests filesystem_runtime_wal_ackcargo test -p warp-core --features "native_rule_bootstrap trusted_runtime host_test" --test trusted_runtime_host_loop_tests runtime_wal_ackcargo clippy -p warp-core --features "native_rule_bootstrap trusted_runtime host_test" --test trusted_runtime_host_loop_tests -- -D warningscargo check -p warp-core --features "native_rule_bootstrap trusted_runtime host_test"cargo fmt --checkpnpm exec prettier --check CHANGELOG.md docs/design/reference-trusted-runtime-host-loop.md docs/design/causal-wal-hardening-matrix.mdpnpm exec markdownlint-cli2 CHANGELOG.md docs/design/reference-trusted-runtime-host-loop.md docs/design/causal-wal-hardening-matrix.mdscripts/check_spdx.sh CHANGELOG.md docs/design/reference-trusted-runtime-host-loop.md docs/design/causal-wal-hardening-matrix.md crates/warp-core/src/trusted_runtime_host.rs crates/warp-core/tests/trusted_runtime_host_loop_tests.rsscripts/ban-nondeterminism.shDETERMINISM_FORCE_NO_RG=1 scripts/ban-nondeterminism.shbash tests/hooks/test_verify_local.shgit diff --check