feat(depot-client): add vfs staging cache ttl#4930
feat(depot-client): add vfs staging cache ttl#4930NathanFlurry wants to merge 1 commit intosqlite-soak/wire-optimization-flagsfrom
Conversation
Code Review: feat(depot-client): add vfs staging cache ttlOverviewThis PR converts the SQLite VFS page cache from a general-purpose second-level cache into a short-lived staging cache for speculative (prefetch/startup) pages. Target pages fetched for IssuesDead code after the refactor
Both are built with
When TTL is 0, committed dirty pages are not staged anywhere. If SQLite pager evicts a recently-written page and re-issues an Page-1 synthesis is duplicated The empty-database page-1 synthesis now lives in two separate arms of
Both paths independently re-derive the same invariant. Extracting the guard into a shared helper would keep them in sync. Unused The standalone Test coverage gapsThe three new tests cover the main TTL/eviction matrix well. Still missing:
Minor notes
SummaryThe staging-cache model is the right direction and the implementation matches the spec. Main items to address before merge: the shared TTL for committed vs. speculative pages, the silent no-op for committed pages when TTL=0, the dead |
17e8f52 to
532acf8
Compare
e5462a4 to
8702157
Compare
|
Code Review: feat(depot-client): add vfs staging cache ttl Overview This PR converts the SQLite VFS page cache from a persistent second-level pager into a short-lived staging cache. Target pages fetched for xRead are no longer retained in VFS memory; speculative (prefetch and startup) pages are cached with a configurable TTL (default 30 s) and evicted when SQLite first reads them. Post-commit dirty pages go into a separate committed_page_cache with the same TTL. The direction is sound. Retaining target pages permanently was redundant since SQLite's internal pager already owns them. Issues
The module-level cache_page function accepts _protected_page_cache: &SccHashMap<u32, Vec> (vfs.rs:899) but never uses it. CLAUDE.md says to avoid backwards-compatibility hacks like renaming unused _vars. Remove the parameter from both the module-level function and the VfsState::cache_page call site that still passes &self.protected_page_cache.
Nothing writes into protected_page_cache after this PR. The eviction in evict_target_read_pages and the clear in invalidate_page_cache are therefore no-ops. Either remove the field entirely or document why it is kept.
build_page_cache is called twice with the same config.cache_capacity_pages, so the total VFS memory ceiling is now 2x the configured limit. This is probably intentional but is undocumented and could surprise operators relying on VFS_PAGE_CACHE_CAPACITY_PAGES to bound memory.
SqliteOptimizationFlags still parses RIVETKIT_SQLITE_OPT_VFS_PROTECTED_CACHE_PAGES, but VfsConfig::from_optimization_flags unconditionally sets protected_cache_pages: 0 and never reads that field. Either deprecate the env var or emit a warning when it is non-zero. Missing test coverage The spec listed five tests; three are present. The two absent:
There is also no test that dirty pages after a commit are readable from committed_page_cache without a depot round-trip. Minor observations
Summary The staging-cache direction is right. Before merging: remove the _protected_page_cache parameter, clean up or remove the dead protected_page_cache field, document or halve the doubled capacity, and either deprecate VFS_PROTECTED_CACHE_PAGES or emit a warning when it is set. Adding the two missing spec tests would also be valuable. |
|
Landed in main via stack-merge fast-forward push. Commits are in main; closing to match. |

Description
Please include a summary of the changes and the related issue. Please also include relevant motivation and context.
Type of change
How Has This Been Tested?
Please describe the tests that you ran to verify your changes.
Checklist: