Fix build SQLITE_BUSY: busy_timeout before a best-effort WAL switch
lib/db.ts switched to WAL at module load before setting busy_timeout.
next build imports it from several workers while the live server holds
the same file, and a journal-mode change needs the file to itself — so
the pragma failed instantly with SQLITE_BUSY and took the whole build
down ("Failed to collect page data"), blocking updates on any box whose
database was still in rollback mode. The timeout is now set first and
the WAL switch is wrapped: a held file keeps its current mode.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Opus 5.5
parent
d462cc284f
commit
1d4d45bd79
@@ -37,8 +37,12 @@ const DB_PATH = process.env.AUTOFIRMER_DB
|
||||
|
||||
mkdirSync(path.dirname(DB_PATH), { recursive: true });
|
||||
const db = new Database(DB_PATH);
|
||||
db.pragma('journal_mode = WAL');
|
||||
db.pragma('busy_timeout = 5000');
|
||||
try {
|
||||
db.pragma('journal_mode = WAL');
|
||||
} catch {
|
||||
// Another connection holds the file; keep its journal mode.
|
||||
}
|
||||
|
||||
// Mirrors the schema in lib/db.ts for every table a restore touches. The app
|
||||
// has usually never run at this point, so the tables may not exist yet; the
|
||||
|
||||
Reference in New Issue
Block a user