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

Aberta
  • Algo errado?
#4,286 1 comentário 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

  • #4293 de @ANSHSINGH050404 — fechado sem integrar
  • #4966 de @kaiizer777 — fechado sem integrar

Avaliação

Dificuldade
2/5
Tempo estimado
1-3 horas
Facilidade para iniciantes
52/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Estagnada
Stack de tecnologia
node.js, typescript
Domínio
cli, tooling

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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
Linguagem predominante
TypeScript
Estrelas
16.5k
Forks
1.5k
Merge médio
1d 15h
PRs com merge (30d)
17

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de triggerdotdev/trigger.dev

Todas as issues de triggerdotdev/trigger.dev

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.