fix(deno): stop replacing cache databases that are still in use

[jgoux]

Fixes #746.

What is wrong

The process can die with SIGBUS (exit 135) while user workers boot at the same time on a fresh DENO_DIR.

1. EmitterFactory::caches() builds a new Caches on every call, and each one opens dep_analysis_cache_v2 and node_analysis_cache_v2. The main service and every user worker have their own factory. The result is several connections initializing the same two SQLite files at once, in the same process.
2. Some of these initializations fail with SQLITE_BUSY, or with SQLITE_CANTOPEN while the parent directory is still being created. After two failures, open_connection deletes the database and creates it again.
3. The new file has a new inode, so SQLite treats the existing -shm file as unused. POSIX locks held by the same process are invisible to F_GETLK, so SQLite truncates the file. Connections that still have the old wal-index mapped then raise SIGBUS on their next access past the first page.

denoland/deno#34873 stops the deletion on lock contention, but it only checks the first error, so a CANTOPEN followed by BUSY still deletes the file.

Changes

• deno/cache/cache_db.rs: every failed attempt is classified, not just the first. BUSY and LOCKED are retried with bounded exponential backoff (about 1.3 s in total). The file is deleted only for SQLITE_CORRUPT and SQLITE_NOTADB. Other failures fall back to the configured on_failure mode as before. That includes a path that still can't be opened after its parent directory is created: it falls back immediately, without deleting anything. The helpers follow fix(cache): retry locked cache database instead of deleting it denoland/deno#34873 (retry_open_with_backoff, log_failure_mode, handle_failure_mode), and the init functions return rusqlite::Error as they do upstream, which should make future syncs easier.

• crates/deno_facade/emitter.rs: caches() is memoized in a Deferred, like the other factory accessors, so each factory opens each cache once.

• The vendored cache_db.rs gets a test module with regression tests:

  • a database locked by another connection is never replaced (checked by inode);
  • CANTOPEN followed by BUSY does not delete the file;
  • contention that never clears falls back without deleting;
  • a path that can't be opened falls back immediately without deleting;
  • a corrupt file is still recreated on disk;
  • concurrent initialization of a fresh cache ends with every connection on the same file.

  Without the fix, the four contention and open-error tests fail every time. The concurrent test is timing-dependent: it failed in 4 of 30 runs, for example with SQLITE_IOERR_SHORT_READ ("file truncated?").

Notes

• In a reproduction that bursts requests at freshly started containers, each creating new user workers, exit 135 went from 31/150 runs to 0/150 with timing-amplified tracing, and from 3/100 to 0/100 without it. The patched runs never deleted a cache database and never fell back to in-memory caches.
• rusqlite already sets a 5 s busy timeout when it opens a connection. The failures above happen in the cases where SQLite returns SQLITE_BUSY without calling the busy handler, so the fix retries with a new connection and leaves the busy timeout as it is.
• Separate factories in one process still open separate connections to the same files. That is safe once nothing replaces a file that is in use. Replacing a corrupt file while another connection in the same process has it open can still cause the same truncation, but that path now needs real corruption. Sharing one Caches per DENO_DIR across the process would remove that case too, and could be done as a follow-up.

🤖 Generated with Claude Code