Verify Prisma 7 against a live database before scheduling the migration (P2002 mapping + migrate deploy on a deployed DB) #186

Blocks #182. This is the prerequisite that has to be answered before the
Prisma 7 migration can be scheduled with any confidence.

The migration change set itself is already written and verified green
(see the investigation on #182): 6 files, ~20 lines, prisma generate
succeeds, tsc clean, 38 suites / 412 tests pass. What could not be
verified is anything requiring a real Postgres — no Docker or local
psql was available.

Two questions, both of which need a live database.

1. Does P2002 still map through the pg driver adapter?

Prisma 7 replaces Prisma's Rust query engine connection with a node-postgres
driver adapter. Error codes are known to shift at the edges — a connection
failure now surfaces as PrismaClientKnownRequestError with
code = 'ECONNREFUSED' where Prisma 5 gave PrismaClientInitializationError
/ P1001.

The codebase branches on exactly three codes:

P2002 is the one that matters. If unique-constraint violations no longer
surface as P2002 through the adapter, signupHandler.ts:188 stops matching
and the Telegram signup flow silently rethrows instead of showing
"email already exists". That is a user-facing regression that no unit test
catches, because every unit test mocks @/db/client.

How to settle it: against a real Postgres, insert a duplicate on a unique
column and assert the thrown error is PrismaClientKnownRequestError with
code === 'P2002'. Worth keeping as a permanent integration test either way.

2. Does migrate deploy work against an already-deployed database?

The 15 migrations in prisma/migrations/ are untouched by the change, and
prisma migrate diff --from-empty emits correct SQL, so the datamodel still
translates. migrate deploy and migrate status both resolve the URL from
prisma.config.ts, load the schema and reach the connect stage — failing only
on P1001: Can't reach database server, which at least confirms the config
wiring is right.

What is unverified is the part that actually carries risk: whether the
_prisma_migrations table written by Prisma 5 is readable by the Prisma 7
engine on an existing deployed database. Checksum and format drift across
major versions is the classic upgrade hazard, and it does not show up against
a fresh database.

How to settle it: run npx prisma migrate deploy against a restored copy
of the deployed database, not a fresh one. CI's integration job already covers
the fresh-database case automatically on the first PR run — that half needs no
extra work.

Why this is separate from #182

#182 is the migration. This is the decision input. The migration has been
deliberately deferred — nothing depends on it, main is green on Prisma 5,
and no security driver was found. It should be scheduled only once these two
answers are known, because #1 in particular determines whether the change is
a half-day or a half-day plus a user-facing bug hunt.

Acceptance

• A live-DB test confirming P2002 still maps correctly under the pg adapter
  (ideally landed as a permanent integration test)
• migrate deploy confirmed against a restored copy of a deployed database
• Findings recorded on Migrate to Prisma 7 (schema datasource + driver adapter + prisma.config.ts) #182 so the migration can be scheduled or re-deferred

Related

• Migrate to Prisma 7 (schema datasource + driver adapter + prisma.config.ts) #182 — the Prisma 7 migration itself (deferred, blocked on this)
• chore(deps-dev): bump prisma from 5.22.0 to 7.9.1 #176 — the dependabot PR; must not be merged, it bumps only the CLI