[blove]

Closes #709.

The bug

The first request to a freshly provisioned schema fails, deterministically:

error: duplicate key value violates unique constraint "pg_namespace_nspname_index" (23505)
GET /readyz -> 503 {"checks":{"requestStores":{"status":"failed"}},"status":"not_ready"}

Root cause

runMigrations takes pg_advisory_xact_lock keyed on schema.prefix.component, and the comment above it says why: the three stores get their own migrations table and their own lock so they version independently and do not serialize against each other. That is right for migrations.

But CREATE SCHEMA IF NOT EXISTS ran inside that same lock, and the schema is the one object all three components share. Three components hold three different locks, so nothing serialized the shared DDL, and IF NOT EXISTS is no more concurrency-safe than the CREATE TABLE IF NOT EXISTS on the next line: the loser raises a duplicate-key error rather than a benign no-op. The partly-created schema is why the reporter saw the checkpointer tables present, the threads and permissions tables missing, and a second run succeed.

This is the cold start after a deploy to a new environment, which is precisely what B4_PG_SCHEMA was added for.

The fix

Schema creation moves into its own short transaction under a lock keyed on the schema alone (schema:<name>). The shared DDL is serialized; the per-component migrations are not, so the independence the component key exists for is preserved.

Kept to a separate transaction deliberately. Holding a schema-wide lock for the length of a migration pass would serialize all three stores against each other, undoing the design. Committing the schema separately is safe because creating one is idempotent and additive, so a later failure leaves an empty schema rather than a wrong one.

Tests

• Real Postgres, gated on B4_TEST_PGSTORAGE=1: the three stores the generated stores.mjs builds call ready() concurrently against a schema that does not exist. This reproduced the exact 23505 on pg_namespace_nspname_index before the change and passes after it, and it then writes and reads a thread to prove the schema is not left half-populated.
• Statement-level, always runs: pins the ordering the fix depends on, that the schema is created under its own lock and committed before the component lock is taken. A future edit cannot quietly fold the DDL back under the component lock.

Validation

• @b4run/postgres-storage full suite with the real-Postgres lane enabled: 9 files, 94 passed
• @b4run/postgres-storage typecheck and lint
• node scripts/check-changesets.mjs

Worth landing before the pending release: postgres-per-environment-schema is one of the changesets waiting in #673, so releasing without this ships a known first-run failure in the feature it belongs to.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
b4-run	Ready	Preview	Sep 18, 2026 2:04am UTC

[github-actions]

Automated approval: this PR received an intelligent (AI) code review. See the review comments on this PR.