The Postgres emulator starts servers one at a time

[wmadden-electric]

# Two servers, started at the same time, in one process:
startPrismaDevServer({ name: 'a', databasePort: 61234 })   ┐ both at once
startPrismaDevServer({ name: 'b', databasePort: 61235 })   ┘
→ PortNotAvailableError { port: 61235 }        # distinct, pinned ports — still fails

# The same two, one after the other:
→ both start fine.

The decision: the Postgres emulator daemon starts servers one at a time. @prisma/dev's start is not concurrency-safe within a process — simultaneous starts choose their ports without seeing each other — and the daemon was issuing exactly that pattern, because an app converges its databases in parallel.

Why this is the whole bug

prisma-composer dev runs an app's Postgres databases as named @prisma/dev servers hosted inside one long-lived daemon. When an app has two databases, the deploy engine converges both resources at once, so two ensure requests hit the daemon simultaneously and it called startPrismaDevServer twice in parallel. One of the two would lose the port race and be refused.

Everything else followed from that. A refused start left a half-started server holding its own name's lock, so the daemon's next attempt for that name was refused a second time — this time as "A Prisma Dev server with the name … is already running." A recovery path added for that message treated the name as a dead leftover and cleared it with @prisma/dev's internal deleteServer, which kills the recorded owner and removes the server's persisted data. On CI that produced, from this single cause: a migrated schema disappearing mid-run (relation "public.product" does not exist), the daemon dying with no JavaScript error at all (its own PGlite files deleted underneath it), and repeated "already running" failures that no amount of retrying could clear.

So this PR fixes the origin and removes the machinery that was generating collisions:

• Starts are serialized. One at a time inside the daemon; a two-database app pays a couple of extra seconds on a cold start and nothing on a warm one.
• The daemon stops choosing @prisma/dev's auxiliary ports. Only the database port is ours to pin, because endpoints recorded in deploy state reference it. The http/shadow/streams listeners are internal to @prisma/dev, and its own picker is the only one that consults its registry of other servers — ours could not, which is what produced the "belongs to another Prisma Dev server" refusals. Net −54 lines of port bookkeeping.
• Nothing on the recovery path deletes anything. A name refused as "already running" means a live process holds that server's lock. Since the name is namespaced to this app and database, that server is the database being asked for: the daemon adopts its connection string, waiting out a holder that is still booting, and clears only a record whose owning process is gone (killServer, which never touches data). The app-scoped DELETE /apps/<app> remains the only caller that deletes.
• Teardown cannot make the daemon kill itself. deleteServer signals whatever pid a server's record names, and for a server hosted inside the daemon that pid is the daemon's own. Teardown now waits for a close to settle before deleting, skips deletion rather than risk a self-kill if it never settles, and never signals a record naming its own process.

Tested

• The two experiments in the opening block were run directly against @prisma/dev — they are what identified the cause, rather than a theory fitted to the logs afterwards.
• New: two databases ensured concurrently both come up and answer select 1 — the exact pattern that used to race.
• New: a live server registered under the daemon-derived name that the daemon has no record of is adopted, its database answers a query, and the daemon stays up. The foreign server runs in its own process, because a record names its host's pid and an in-process one would make teardown kill the test runner.
• The full daemon suite, the local-target suite, and the store integration proof (four prisma-composer dev sessions, including --fresh and warm restart) pass on CI, along with all three deploy smokes and both canaries.

Alternatives considered

• Keep retrying harder — the branch history is a record of this failing: wider port-retry windows, longer adoption patience, process-level crash guards. Each addressed a symptom the concurrency bug produced, and the failures kept moving.
• Let @prisma/dev pick the database port too — deploy state records the port, so it has to stay stable across restarts; only the internal listeners can float.
• Serialize in the provider instead of the daemon — providers run in a short-lived converge process, and the daemon is the shared thing that actually owns the servers; a lock anywhere else would not cover a second dev session.

🤖 Generated with Claude Code

[coderabbitai]

Walkthrough

The Postgres emulator now reconciles persisted server records before startup and during name-conflict recovery. It adopts servers with live owning processes and recorded URLs, clears stale live records when owning processes are dead, and bounds polling retries while a server is booting. Adopted-server teardown avoids killing the daemon itself, waits for persisted close settlement, and deletes state only after settlement. A cross-process test verifies adoption, connectivity, daemon health, and cleanup.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	It summarizes the main behavior change: Postgres emulator startup is serialized.
Description check	✅ Passed	It describes the same server-conflict and serialization fix reflected in the diff.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch claude/local-dev-ghost-adoption-fix

✨ Simplify code

• Create PR with simplified code
• Commit simplified code in branch claude/local-dev-ghost-adoption-fix

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/@prisma/composer@167

npm i https://pkg.pr.new/@prisma/composer-prisma-cloud@167

commit: a96bb92

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@packages/1-prisma-cloud/0-lowering/dev-emulators/src/postgres-main.ts`:
- Around line 482-510: Document the changed recovery behavior around the
isNameAlreadyTaken/adoption flow: truly orphaned locks that never expose an
adoptable server exhaust MAX_ADOPT_ATTEMPTS and return a 500 until DELETE
/apps/<app> is performed. Update the relevant on-call runbooks and alerts to
identify this condition and prescribe manual deletion, while preserving the
existing protection against deleting live server state.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 95bf69e2-ce28-47fb-91bc-c8662cedc2e0

📥 Commits

Reviewing files that changed from the base of the PR and between 3142847 and 0aeef0d.

📒 Files selected for processing (1)

• packages/1-prisma-cloud/0-lowering/dev-emulators/src/postgres-main.ts