bug: Prisma extension intermittently selects wrong version with pnpm workspaces and catalogs
Problem Description
When using Trigger.dev with pnpm workspaces that utilize catalogs, the Prisma extension can intermittently select the wrong Prisma version during builds. This appears to be a race condition in the version resolution logic.
Environment
Repository Structure
project-root/
├── pnpm-workspace.yaml (with catalogs definition)
├── trigger.config.ts
├── prisma/
│ └── schema.prisma
└── node_modules/
pnpm-workspace.yaml Configuration
packages:
- src/trigger/*
catalogs:
prisma:
'@prisma/client': '~6.16.0'
prisma: '~6.16.0'
trigger.config.ts
prismaExtension({
schema: "prisma/schema.prisma",
// version was sometimes needed to be specified explicitly to work around this issue
version: "6.16.2",
clientGenerator: "client"
})
Issue Details
The problem occurs when:
- Using pnpm workspaces with multiple sub-packages
- Using pnpm catalogs to centralize dependency versions
- Prisma schema is in the root project directory
- No explicit version is specified in the Prisma extension configuration
What Happens
- Sometimes the correct version is detected
- Sometimes the wrong version is selected
Root Cause
The issue stems from how resolvePackageJSON walks up the directory tree when resolving packages in pnpm's symlinked structure. It can find:
- The wrong package.json (parent workspace instead of @prisma/client)
- A marker package.json file with incomplete information
- Nothing at all due to symlink traversal issues
Current Workaround
Explicitly specify the version in trigger.config.ts:
prismaExtension({
schema: "prisma/schema.prisma",
version: "6.16.2", // Explicitly specify to avoid race condition
clientGenerator: "client"
})
Solution
PR #2555 addresses this issue by:
- Fixing the package.json resolution to verify the correct package is found
- Adding fallback to read version directly from node_modules
- Supporting pnpm workspace: protocol
- Providing helpful error messages for catalog: references
Related PR: #2555
I am not sure exactly if this is the correct fix, but we observed that every second time we tried to build there was some kind of race condition which would select the wrong prisma version (version 5.x.x), this failed our build as we were using some new features from 6.
Now just simply retrying the github actions build fixed the issue sometimes, or retrying a few times fixed it, so there was obviously something a bit quirky about how the version is detected.
The workaround for now without this fix is to manually specify the version, however that's annoying, it should just detect it correctly as intended.
Some additional details, thanks @hongkongkiwi 🙏
for reproducing [...] use prisma version 6 with a specific feature that isn't available in 5. Such as having a primary id as cuid(2) because [...] 5 will build everything just fine and you woudln't notice
prismaExtension({
schema: "prisma/schema.prisma",
version: "6.16.3",
clientGenerator: "client",
}),
Also, might not happen on manual builds, only CI (GitHub Actions)