bug: starting a second `trigger dev` session can crash it or silently break rebuilds

Ouverte
  • Quelque chose ne va pas ?
#4,286 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

  • #4293 par @ANSHSINGH050404 — fermée sans fusion
  • #4966 par @kaiizer777 — fermée sans fusion

Évaluation

Difficulté
2/5
Temps estimé
1-3 heures
Accessibilité débutants
52/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
À l'abandon
Stack technique
node.js, typescript
Domaine
cli, tooling

Piste de recherche

Read packages/cli-v3/src/utilities/tempDirectories.ts and packages/cli-v3/src/utilities/fileSystem.ts, focusing on store-directory cleanup and createFileWithStore(). Reproduce by deleting .trigger/tmp/store during a running dev session and changing a task file. Done means the rebuild completes and repopulates the store; the issue suggests adding a regression test but names no test file.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Provide environment information

System:
OS: macOS 26.6
CPU: (14) arm64 Apple M4 Pro
Memory: 454.95 MB / 48.00 GB
Shell: 5.9 - /bin/zsh
Binaries:
Node: 24.14.0 - /Users/cheema/.local/state/fnm_multishells/3536_1784491292657/bin/node
Yarn: 1.22.22 - /opt/homebrew/bin/yarn
npm: 11.9.0 - /Users/cheema/.local/state/fnm_multishells/3536_1784491292657/bin/npm
pnpm: 10.25.0 - /opt/homebrew/bin/pnpm
bun: 1.3.5 - /Users/cheema/.bun/bin/bun

trigger.dev CLI 4.5.4, @trigger.dev/sdk 4.5.4

Describe the bug

I hit this while setting up a new project. I had trigger dev running, started another dev session for the same project, and the new one crashed mid-build with an uncaught ENOENT writing to .trigger/tmp/store/<hash> (screenshot below, stack included).

Digging into the CLI source, here is what I believe happens. getStoreDir() (packages/cli-v3/src/utilities/tempDirectories.ts) creates .trigger/tmp/store when a dev session starts and registers an exit handler that deletes it recursively. The path is deterministic per project and branch, so every dev session of the same project shares it. When you start a second session, the takeover makes the first one exit, and its cleanup deletes the store out from under the new session. createFileWithStore() (packages/cli-v3/src/utilities/fileSystem.ts) ensures the build file's parent directory before writing, but not the store directory, so the next store write fails.

The timing decides what you see. If the cleanup lands during the new session's initial build, it crashes loudly like mine did. If it lands later, the next watch rebuild prints "Rebuilding local worker…" and hangs forever with no error output, which is the nastier version; that one reproduces deterministically. And if the old process happens to die without running its cleanup, nothing breaks at all, which is probably why this can look intermittent.

Reproduction repo

Not project-specific: reproduces on any project with the steps below (it's a CLI dev-session race, no special code involved).

To reproduce

Organic: run npx trigger.dev@latest dev, wait for "Local worker ready", then start a second trigger dev for the same project in another terminal. Depending on where the old session's cleanup lands, the new session either crashes with the ENOENT mid-build (screenshot) or hangs silently on a later rebuild.

Deterministic shortcut for the hang variant: with one dev session running, delete .trigger/tmp/store (the same deletion the exit cleanup performs), then make any content change to a task file. The rebuild starts and never finishes, with no error output.

Additional information

A one-line fix works: ensure the store directory exists in createFileWithStore right before the store write, the same way the function already ensures the build path a few lines earlier. I patched my local install with it and the exact repro heals: the rebuild completes and the store gets repopulated. Happy to open that PR with a regression test once vouched.

One side observation from debugging: watch-rebuild errors seem to get swallowed entirely, which is what turns this case into a silent hang instead of a visible error.

Image
Langage dominant
TypeScript
Étoiles
16.5k
Forks
1.5k
Merge moyen
1 j 15 h
PR mergées (30 j)
17

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de triggerdotdev/trigger.dev

Toutes les issues de triggerdotdev/trigger.dev

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.