trigger.dev icon indicating copy to clipboard operation
trigger.dev copied to clipboard

bug: Prisma extension intermittently selects wrong version with pnpm workspaces and catalogs

Open hongkongkiwi opened this issue 3 months ago • 2 comments

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:

  1. Using pnpm workspaces with multiple sub-packages
  2. Using pnpm catalogs to centralize dependency versions
  3. Prisma schema is in the root project directory
  4. 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:

  1. Fixing the package.json resolution to verify the correct package is found
  2. Adding fallback to read version directly from node_modules
  3. Supporting pnpm workspace: protocol
  4. Providing helpful error messages for catalog: references

Related PR: #2555

hongkongkiwi avatar Sep 25 '25 14:09 hongkongkiwi

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.

hongkongkiwi avatar Sep 25 '25 14:09 hongkongkiwi

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)

nicktrn avatar Oct 31 '25 16:10 nicktrn