mirror of
https://github.com/aphrody-labs/deno.git
synced 2026-10-14 06:19:28 +00:00
a9f636ac8e
When opening a cache database fails because another process is currently
operating on it (`SQLITE_BUSY` / `SQLITE_BUSY_RECOVERY` — e.g.
recovering a WAL-mode database file, surfaced as error code 261), the
underlying file is **not** corrupt. Previously Deno would log a warning,
delete the database, and recreate it:
```
Could not initialize cache database .../v8_code_cache_v2, deleting and retrying... (database is locked
Caused by:
Error code 261: Another process is recovering a WAL mode database file)
Failed to open cache file .../v8_code_cache_v2, performance may be degraded.
```
This is both noisy and destructive — it deletes a database another
process is actively recovering. As suggested by @lucacasonato in the
issue, this just means "wait, some other process is fixing the db right
now".
## Change
In `cli/cache/cache_db.rs` `open_connection()`:
- Detect transient lock-contention errors (`rusqlite` `SqliteFailure`
with `ErrorCode::DatabaseBusy` or `DatabaseLocked`; note
`SQLITE_BUSY_RECOVERY` maps to the `DatabaseBusy` primary code).
- Retry opening the database with **exponential backoff** (7 attempts,
10ms base doubling, capped at 1s, ~1.3s total) instead of the
delete-and-retry path.
- If the contention does not clear, degrade gracefully to the configured
failure mode (in-memory cache) **without deleting the file**, since it
belongs to another process and is not corrupt.
Non-contention errors still take the existing retry/delete/recover path
unchanged.
## Tests
Added two unit tests in `cli/cache/cache_db.rs`:
- `lock_contention_retries_then_succeeds` — busy errors are retried and
succeed once contention clears; the file is not deleted.
- `lock_contention_does_not_delete_on_giving_up` — persistent busy
errors fall back to in-memory without deleting the on-disk file.
`cargo test -p deno --lib cache_db` passes (10/10).
Closes #27283
Closes denoland/divybot#479
Co-authored-by: divybot <divybot@users.noreply.github.com>
Co-authored-by: Divy Srivastava <me@littledivy.com>