Repository navigation
Conversation
|
|
|
Important Review skippedReview was skipped as selected files did not have any reviewable changes. ⚙️ Run configuration
You can disable this status message by setting the Use the checkbox below for a quick retry:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Mergeability Score: ⚪ Minimal · up to The change is localized to query serialization and its associated tests; no actionable merge-blocking risk remains beyond normal checks and review. 🚥 Pre-merge checks | ✅ 5
✨ Finishing Touches
Comment |
| return this.#performIO(query) | ||
| } | ||
| const previous = this.#queryLock | ||
| const current = previous.then(() => this.#performIO(query)) |
There was a problem hiding this comment.
This will reject all pending queries with the exact same error if a previous query in the chain fails, which sounds undesirable
There was a problem hiding this comment.
The previous version did isolate errors (the stored chain was always current.catch(() => {}), so a failure only rejected its own caller; the "keeps serializing after a failed query" test covers exactly this scenario).
That said the code did not express well this intent : the lock is now a resolve-only Promise<void> that just signals completion of the previous query, so an error structurally can't enter the chain.
7139956 to
9adde52
Compare
|
@aqrln could you approve the CI run when you get a chance please? |
|
@aqrln I hope you are doing well ! |
A pg.PoolClient is a single connection and does not support concurrent queries (deprecated in pg@8, an error in pg@9), but the query interpreter loads sibling relations concurrently, so any query with 2+ relations inside a transaction triggered the deprecation warning. Serialize performIO in PgQueryable for single-connection clients, leaving the pool path parallel. Supersedes prisma#29468, fixes prisma#29407. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Camille Barneaud <1693643+gadcam@users.noreply.github.com>
Restructure the serialization lock so it can never carry a query's error: the lock promise only signals completion, and a failed query rejects its own caller only. Use timers.setImmediate() in tests and derive the join-child type from the query plan instead of asserting. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Camille Barneaud <1693643+gadcam@users.noreply.github.com>
9adde52 to
a8ab7fe
Compare
|
Confirming this on The diagnosis in this PR matches what I see: the warning fires on a multi-relation read inside Minimal shape that triggers it here, a nested include inside an interactive transaction: await prisma.$transaction(async (tx) =>
await tx.item.update({
where: { id },
data: { status: 'ACTIVE' },
include: { acounts: { include: { liability: true } } },
});
});Emitted once per process, as expected for What makes this more than cosmetic: pg@9 turns the deprecated path into a hard error, so the warning is a forward-compatibility signal rather than noise. Applications can't fix it themesleves -- the Happy to test a build of this branch against a real app if that's useful. |
|
@SevInf could you take a look when you have a chance? |
…g@9 hold - previewSupplierDebitNote no longer console.errors a ZodError (incomplete form, e.g. missing reason); it still rethrows so the action returns the Thai message, and every other failure still logs. - Golden test: incomplete form logs nothing, a service failure still logs. - PLAN.md: post-lifecycle-fix [db-retry] results (0 gave-up, diagnostics kept), hold pg at 8.x until prisma/orm#29979 lands (Prisma 7 join node runs include relations concurrently on one transaction connection), and the Z1-Z3 deploy result line. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…g connection Prisma 7 loads sibling relations (2+ in one include / nested select) with Promise.all. Inside an interactive transaction they share one pg connection, so pg@8 queued them and logged "DeprecationWarning: Calling client.query() when the client is already executing a query" (credit-note create/edit on 2026-10-04, via rebuildCreditNoteProfitFacts); pg@9 makes it an error. FluidPrismaPg now wraps each transaction's queryRaw/executeRaw in a resolve-only promise queue, mirroring prisma/orm#29979. Pool queries outside a transaction stay concurrent. The golden test runs Prisma's real query interpreter against a fake connection; its canary fails once @prisma/adapter-pg serializes by itself, signalling the wrapper can go. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This branch has not been deployed
4 participants
Problem
@prisma/adapter-pgemitsDeprecationWarning: Calling client.query() when the client is already executing a querywhenever a query with 2+ sibling relations runs inside a transaction. The query interpreter'sjoinnode loads relations concurrently; apg.Pooltolerates this, but a transaction's singlepg.PoolClientdoes not — and pg@9 will make it a hard error.Fixes #29407.
Fix
Per @aqrln's review on #29468, serialization is done in the base
PgQueryable.performIOrather than inPgTransaction— the constraint is the single connection, not transactions per se.PrismaPgAdapteropts out via aserializeQueriesflag: the pool manages its own concurrency, and serializing it would cap the whole application at one query at a time. A small promise-chain lock replaces #29468'sasync-mutexdependency.The interpreter is deliberately untouched: join fan-out stays parallel (a regression test now pins this) and adapters own the serialization.
Tests
client.query()calls (fails without the fix)joinchildren still load in parallelCredit
This supersedes #29468 by @matingathani, who identified the issue and proposed the original mutex approach — picking it up as the review feedback has been open since 2026-07-28. Thanks also to @tensordreams for their contributions to that branch.
🤖 Generated with Claude Code
Summary by CodeRabbit
Bug Fixes
Tests