From b229520f8e917021852dc5215f40a4db403fd5cd Mon Sep 17 00:00:00 2001 From: Richard Feldman Date: Thu, 12 Feb 2026 11:26:13 -0500 Subject: [PATCH] Increase SQLite busy_timeout from 1ms to 500ms (#49039) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit When two Zed instances share the same data directory (e.g. a release build and a dev build running simultaneously), SQLite operations can fail with "database is locked" (error code 5), surfacing as a "Failed to Launch" error in the agent panel. The root cause is `PRAGMA busy_timeout=1` in `crates/db/src/db.rs`, which gives SQLite only 1ms to wait for a write lock before giving up. With WAL mode, the actual lock hold times are microseconds — the problem isn't long-held locks, it's that we give up before even trying to wait. During startup, both instances hit the DB heavily for workspace restoration, so even tiny overlaps fail. This changes `busy_timeout` from 1ms to 500ms, giving SQLite more room to retry without (hopefully) any perceptible delay to the user. Closes AI-20 Release Notes: - N/A --- crates/db/src/db.rs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/crates/db/src/db.rs b/crates/db/src/db.rs index eab2f115d8e5c3db51541544a8dbc95f34713741..36f0365af97ed05859d0c1116065adb004dec2d9 100644 --- a/crates/db/src/db.rs +++ b/crates/db/src/db.rs @@ -28,7 +28,7 @@ const CONNECTION_INITIALIZE_QUERY: &str = sql!( const DB_INITIALIZE_QUERY: &str = sql!( PRAGMA journal_mode=WAL; - PRAGMA busy_timeout=1; + PRAGMA busy_timeout=500; PRAGMA case_sensitive_like=TRUE; PRAGMA synchronous=NORMAL; );