fix(cache): synchronous=NORMAL on the persistent HTTP cache (fsync tolerance)#266
Open
cubehouse wants to merge 1 commit into
Open
fix(cache): synchronous=NORMAL on the persistent HTTP cache (fsync tolerance)#266cubehouse wants to merge 1 commit into
cubehouse wants to merge 1 commit into
Conversation
…lerance) The on-disk cache runs WAL but synchronous=FULL, so DatabaseSync fsyncs on every commit. During a park's entity/sync sweep the cache is written heavily, and on a slow or saturated disk (a consumer SATA SSD under sustained O_DSYNC load) each synchronous write stalls the caller's event loop on a full fsync. WAL + synchronous=NORMAL fsyncs only at checkpoints; the only risk is losing the last uncheckpointed cache rows on a hard crash, which are simply re-fetched. Test (cachePragmas.test.ts) re-imports the module against a real on-disk path (the shared setup forces :memory:) and asserts journal_mode=wal + synchronous=1. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KPNw8f4pE63C9hE2Xy4ykt
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Companion to collector PR #81. The on-disk HTTP cache (
cache.sqlite) runs WAL butsynchronous=FULL, soDatabaseSyncfsyncs on every commit. During a park's entity/sync sweep the cache is written hard, and because the call is synchronous, on a slow/saturated disk each write stalls the caller's event loop on a full fsync. (Concretely: a collector agent on a consumer SATA SSD was fsyncing ~30ms under load, wedging the loop and starving live pushes.)WAL + synchronous=NORMALfsyncs only at checkpoints, not per commit. This is the biggest single burst-writer of the SQLite DBs involved.Safety
The only durability change is losing the last uncheckpointed cache rows on a hard crash — a cache miss that re-fetches. No correctness impact.
Test
cachePragmas.test.tsre-imports the module against a real on-disk path (the sharedvitest.setup.tsforces:memory:, where journal_mode is 'memory') and assertsjournal_mode=wal+synchronous=1(NORMAL). Existingcache.test.tsunaffected (81/81).🤖 Generated with Claude Code
https://claude.ai/code/session_01KPNw8f4pE63C9hE2Xy4ykt