From 12e547d71efe99a84b4213be264343cfab2520e4 Mon Sep 17 00:00:00 2001 From: Oleg Date: Wed, 5 Aug 2026 10:26:34 +0000 Subject: [PATCH] Migrate before build, not just before start, to fix build-time SQLITE_BUSY MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit next build's page-data collection runs several parallel workers that each import the db client at module-eval time. When data/db.sqlite doesn't exist yet, every worker raced to create it from scratch — a race at the file-creation level itself, before our code ever gets to run a busy_timeout pragma, so pragma ordering alone (previous commit) wasn't enough to fix it. Running db:migrate as its own isolated, single-process build step first means the workers only ever see an already-existing, already-stable file. The runtime volume-mounted DB is unaffected — it's still migrated again (as a no-op once applied) by the existing CMD. Co-Authored-By: Claude Sonnet 5 Claude-Session: https://claude.ai/code/session_012o9j9RezxbZVKQMrB7oRLY --- Dockerfile | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/Dockerfile b/Dockerfile index 92675ca..721c6f6 100644 --- a/Dockerfile +++ b/Dockerfile @@ -12,6 +12,14 @@ COPY package.json package-lock.json ./ RUN npm ci COPY . . +# `next build`'s page-data collection spins up several parallel workers that +# each import the db client at module-eval time. If data/db.sqlite doesn't +# exist yet, every worker races to create it from scratch — that race is at +# the file-creation level, before our code ever gets to run a busy_timeout +# pragma, so it can throw SQLITE_BUSY (or worse) independent of pragma order. +# Migrating first — as its own isolated, single-process step — means the +# workers only ever see an already-existing, already-stable file. +RUN mkdir -p data && npm run db:migrate RUN npm run build ENV NODE_ENV=production