8000 store: WAL journaling so streamed deltas commit cheaply by Mnehmos · Pull Request #24 · Mnehmos/dagos · GitHub
[go: up one dir, main page]

Skip to content

store: WAL journaling so streamed deltas commit cheaply - #24

Merged
Mnehmos merged 1 commit into
mainfrom
fix/streaming-commits
Sep 24, 2026
Merged

Mnehmos merged 1 commit into
mainfrom
fix/streaming-commits

Conversation

@Mnehmos
@Mnehmos Mnehmos commented Sep 24, 2026
Copy link
Copy Markdown
Owner

Fixes the flaky Windows CI failure seen on da25a12 (inspector tests).

Root cause: every streamed delta is its own committed event. With SQLite's default journal and synchronous = FULL, each commit waits for the disk: 10.8 ms per delta on a fast local SSD, and much more on a busy CI runner. The four inspector tests that run their workspaces in parallel exceeded their inference deadline together (all failed about 24 s in). The fifth test, which ran after them, passed.

Fix: file stores use WAL with synchronous = NORMAL. Commits no longer wait for the disk: 0.16 ms per delta locally, about 68× faster. The database cannot be corrupted, and at worst the last moments before a power failure are lost; such a run is marked interrupted on restart. A new test checks that file stores commit through the log and survive a restart. The earlier hardening (tests no longer read real saved keys, a longer deadline, and failures that say why) stays.

🤖 Generated with Claude Code

Root cause of the flaky Windows CI failure in the inspector tests: every
streamed delta is its own committed event, and with SQLite's default rollback
journal and `synchronous = FULL` each commit waited for the disk (10.8 ms per
delta on a fast local SSD, far more on a busy CI runner with several workspaces
streaming at once). The four tests that ran their workspaces in parallel
exceeded their inference deadline together; the one that ran after them passed.

File stores now use WAL with `synchronous = NORMAL`: a commit appends to the
log without waiting for the disk (0.16 ms per delta locally, about 68x faster),
the database cannot be corrupted, and at worst the last moments before a power
failure are lost (such a run is failed as interrupted on restart).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@chatgpt-codex-connector
Copy link
Copy Markdown

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

@coderabbitai
coderabbitai Bot commented Sep 24, 2026
Copy link
Copy Markdown

Important

  • 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Advanced

Run ID: a7e6cd8a-ba4c-4072-a867-f0c29ed2ea8d


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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@Mnehmos
Mnehmos merged commit ca0bcbf into main Sep 24, 2026
4 checks passed
@Mnehmos
Mnehmos deleted the fix/streaming-commits branch September 24, 2026 16:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant

0