Conversation
|
bugbot run |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
size-limit report 📦
|
|
bugbot run |
01e2f54 to
5acb09a
Compare
5acb09a to
b618c97
Compare
|
bugbot run |
| const db = prismaPostgres.default({ contractJson, url }); | ||
| // With `require(esm)` the module-injection notice arrives on a later tick, so a call in the same | ||
| // tick as the require would run before the SDK subscribes to the channels. | ||
| await new Promise(resolve => setImmediate(resolve)); |
There was a problem hiding this comment.
m/q: Isn't that an issue users would face too?
There was a problem hiding this comment.
Yes, in one narrow case. A CJS app on Node 22 to 24.12 loads this ESM-only package through require(esm), which Node routes through the async module hooks. The hook thread transforms the file and posts the "module injected" notice over a message port, so the main thread only processes it on a later tick. An ORM call made in the very same tick as the require therefore runs before the SDK subscribes to the channels and gets no operation span; anything after the first await is covered. Real apps make their first query after startup, so I left it as a documented edge (also in the PR body of #24682). It is inherent to the async-hook path for any ESM-only dependency required from CJS, not Prisma specific; from Node 24.13 / 25.1 the sync hooks make it disappear. Happy to look at subscribing eagerly for that path in a follow-up if we think it matters.
| await db.orm.public.User.where(user => user.email.like('%sentry.io')).delete(); | ||
|
|
||
| setTimeout(async () => { | ||
| span.end(); |
There was a problem hiding this comment.
l/q: Is this span.end() needed in this scenario? Since setTimeout is not blocking and would have ended the span by then already
There was a problem hiding this comment.
Right, that end was a no-op. Removed the timer and the manual end; the span ends when the callback resolves, and db.close() now runs after it.
b618c97 to
351c658
Compare
|
bugbot run |
Prisma 8 ("Prisma Next") ships no tracing surface, so `prismaIntegration`
is inert there and only the `pg` query spans remain. Pin that behaviour
against 8.0.0-rc.8 so a Prisma release that adds a tracing surface, or
breaks the `pg` path, shows up.
The emitted `contract.json` and an `init.sql` dumped from `prisma-cli db
init` are committed: the Prisma 8 CLI needs Node 22.18+ and breaks npm's
peer-dependency resolution. The contract has no `DateTime` column, since
Prisma 8 decodes timestamps into `Temporal`, global only on Node 26.
The runner's ESM-to-CJS converter now drops `with { type: 'json' }`
import attributes so the scenario can import the contract.
Refs #24237
Co-Authored-By: Claude Fable 5.1 <[email protected]>
|
bugbot run |
351c658 to
5430d50
Compare
|
bugbot run |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 5430d50. Configure here.
This branch has not been deployed
2 participants
Prisma 8 ("Prisma Next", rc.8) has no tracing surface, so
prismaIntegrationis inert there. This suite pins what we get today: only thepgquery spans frompostgresIntegration.contract.json/init.sqlare committed: the Prisma 8 CLI needs Node ≥ 22.18 and breaks npm's peer resolution.with { type: 'json' }import attributes.Refs #24237