fix(cache): store database in per-schema-version directory#433
Conversation
The task cache was one shared cache.db keyed only by an in-DB user_version. An older vp build opening a database written by a newer build aborted with "Unrecognized database version", so switching between branches that pin different Vite+ versions broke the cache. Store the cache in a per-schema-version subdirectory (e.g. task-cache/v13/) so incompatible builds use separate databases and stay warm across branch switches. An unrecognized database is now rebuilt instead of aborting, and a one-time sweep removes the legacy top-level cache files. Closes voidzero-dev/vite-plus#1785
Use an exhaustive match for the database schema-version check instead of a loop with stacked ifs, and inline the version-set statement into the create arm. Run the one-time legacy-layout cleanup lazily on first cache open rather than on every session startup, so commands that never touch the cache don't pay for it. No behavior change.
Plants a pre-versioned top-level cache.db and an orphaned .tar.zst, then asserts the first run sweeps them and recreates the cache under the per-version subdirectory, with the second run hitting the migrated cache.
Assert on extension-filtered listings (the cache db left the top level and reappears nested) instead of snapshotting the literal v13 directory, so the test survives a CACHE_SCHEMA_VERSION bump.
|
@cursor review |
|
@codex review |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 30f24a6. Configure here.
|
Codex Review: Didn't find any major issues. Swish! ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
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". |
The per-version cache directory already isolates incompatible schemas, so the in-database user_version is redundant: remove the PRAGMA query, the match/reset loop, and the legacy-layout sweep. load_from_path now just ensures the tables exist (CREATE TABLE IF NOT EXISTS). A cache left by another version is harmlessly ignored (it lives in a directory this build never opens) and reclaimable via vp cache clean, which still wipes the whole task-cache base. Replace the migration e2e fixture with one asserting the leftover is ignored.
Fold the WAL pragma and the two CREATE TABLE IF NOT EXISTS statements into one execute_batch, so opening the cache is one SQLite call instead of three. On an existing database the IF NOT EXISTS creates are near-free no-ops; load_from_path runs once per process (OnceCell).
|
@cursor review |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 1a1937f. Configure here.
The name collided with execute/mod.rs's `cache_base_path`, which means the
workspace root that cached relative paths anchor to. This field is the parent
of all `vN` version dirs, so `cache_root` is clearer and pairs with the
versioned sibling `cache_path` (cache_root.join("v13")).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
It is only referenced within the module (by cache_schema_dir_name), so the `pub` was unnecessary. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This stack of pull requests is managed by Graphite. Learn more about stacking. |
## Why `crates/vite_task` had two unrelated fields both named `cache_base_path`, which was a trap for anyone reading across the cache code: - In [`session/mod.rs`](crates/vite_task/src/session/mod.rs), it meant the **cache directory** — the parent of all `vN` schema-version subdirs. - In [`execute/mod.rs`](crates/vite_task/src/session/execute/mod.rs), it meant the **workspace root** — the directory that relative paths stored in cache entries (inputs, outputs, archives) are resolved against. It is literally set to `self.workspace_path`. Same name, opposite halves of the cache machinery (where the cache lives vs. what cached paths point at). ## What This PR renames the `execute` one to `workspace_root`, naming it for the value it actually holds and disambiguating it from the cache directory. The doc comment is updated to spell out the role. All 10 references (the `ExecutionContext` field and the `execute_spawn` parameter it feeds) are renamed. The `session` field was renamed to `cache_root` in the parent PR (#433), so after both PRs the two concepts read clearly: | Field | Where | Meaning | | --- | --- | --- | | `cache_root` | session | parent of all `vN` cache dirs | | `cache_path` | session | this build's versioned dir (`…/v13`) | | `workspace_root` | execute | dir that cached relative paths anchor to | | `cache_dir` | execute | where cache files (db, archives) are stored | Pure rename + doc tidy; no behavior change. `cargo check -p vite_task` passes. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

The task cache was one shared
cache.dbkeyed only by an in-DBuser_version. An oldervpbuild opening a database written by a newer build aborted withUnrecognized database version, so switching between branches that pin different Vite+ versions broke the cache.Store the cache in a per-schema-version subdirectory (e.g.
node_modules/.vite/task-cache/v13/) so incompatible builds use separate databases and stay warm across branch switches. An unrecognized database is now rebuilt instead of aborting, and a one-time sweep removes the legacy top-level cache files.Closes voidzero-dev/vite-plus#1785
Note
Medium Risk
Changes where and how the SQLite task cache is created and cleaned, which affects all cached runs; behavior is simpler but users may retain orphaned legacy top-level cache files until they run
cache clean.Overview
Fixes branch switches between Vite+ versions that previously aborted with
Unrecognized database versionwhen an older build opened a newercache.db.The task cache now lives under a schema-version subdirectory (e.g.
node_modules/.vite/task-cache/v13/). Session init writes only there;cache cleanremoves the wholetask-cachetree (all versions plus any legacy top-level files). Opening the DB drops in-DBuser_versionmigration and version-mismatch errors in favor ofCREATE TABLE IF NOT EXISTSin that versioned folder, so each pinned version keeps an isolated warm cache and stale top-levelcache.dbfiles are never opened.Test support:
vtt list-dir --recursivefinds archives under nested version dirs; new unit and e2e coverage covers version isolation and ignored legacy cache paths.Reviewed by Cursor Bugbot for commit 1a1937f. Configure here.