Type: runtime lifecycle bug. Target: prisma/orm PostgreSQL runtime.
The standalone case constructs a fresh pg.Pool with max: 1 and connectionTimeoutMillis: 150, supplies it to the Prisma runtime, and makes its first query inside native.transaction(...). The marker read fails with CONTRACT.MARKER_READ_FAILED; its cause reports a connection acquisition timeout. The same initialized database is successfully queried by the already primed runtime in the other cases.
The transaction reserves the only connection before first-use marker verification tries to acquire a connection through the pool. With no acquisition timeout this can stall rather than reporting a useful bounded failure. Increasing pool size can hide the issue, but it leaves first-use behavior dependent on concurrent connection availability.
Expected behavior: a first query inside a transaction should succeed with a valid initialized database and a one-connection pool, without requiring another pool connection for marker verification. Marker verification should remain enabled.
Regression scope: fresh pool size one, successful first query inside a transaction, concurrent first transactions, marker mismatch/missing marker, cancellation and failed acquisition cleanup.
Primary source: SQL runtime marker lifecycle, PostgreSQL driver.
Environment
@prisma/orm-postgres: 8.0.0-rc.8 (the live latest tag when reverified September 6, 2026)- Prisma CLI:
8.0.0-rc.13
- TypeScript:
5.9.3
- Node:
26.5.0
- npm:
11.17.0
- OS: macOS 26.6.2 arm64
- PostgreSQL:
14.23 for database-backed cases
Type: runtime lifecycle bug. Target: prisma/orm PostgreSQL runtime.
The standalone case constructs a fresh
pg.Poolwithmax: 1andconnectionTimeoutMillis: 150, supplies it to the Prisma runtime, and makes its first query insidenative.transaction(...). The marker read fails withCONTRACT.MARKER_READ_FAILED; its cause reports a connection acquisition timeout. The same initialized database is successfully queried by the already primed runtime in the other cases.The transaction reserves the only connection before first-use marker verification tries to acquire a connection through the pool. With no acquisition timeout this can stall rather than reporting a useful bounded failure. Increasing pool size can hide the issue, but it leaves first-use behavior dependent on concurrent connection availability.
Expected behavior: a first query inside a transaction should succeed with a valid initialized database and a one-connection pool, without requiring another pool connection for marker verification. Marker verification should remain enabled.
Regression scope: fresh pool size one, successful first query inside a transaction, concurrent first transactions, marker mismatch/missing marker, cancellation and failed acquisition cleanup.
Primary source: SQL runtime marker lifecycle, PostgreSQL driver.
Environment
@prisma/orm-postgres:8.0.0-rc.8(the livelatesttag when reverified September 6, 2026)8.0.0-rc.135.9.326.5.011.17.014.23for database-backed cases