What happened
trigger.dev@4.5.11 declares esbuild ^0.23.0. Our repo had a root-level npm overrides entry pinning esbuild to 0.25.0, added for GHSA-67mh-4wv8-2f99. npm honours the override, so the CLI bundled with 0.25.0 without warning.
esbuild 0.25.0 has an out-of-bounds source-index regression, fixed in 0.25.1, that drops input sources entries while keeping the mapping indices. Two of our deployed chunks came out internally inconsistent:
trigger/slack-attention-agent.mjs.map: 6 sources, mappings referencing index 37
- a shared
ai chunk: 171 sources, mappings referencing index 200
Impact
The worker installs source-map-support globally (entryPoints/managed-run-worker.js). Once a stack contained a frame from either chunk, originalPositionFor threw Error: No element indexed by 6. recordSpanException (otel/utils.ts) and the AI SDK's default error handler (console.error(error)) both read .stack without a guard, so that exception replaced the error being reported.
Every chat.agent turn failed for a week with No element indexed by 6. The original error never surfaced anywhere, including in streamText's onError, which received the substituted message instead. Scheduled tasks on the same deployment kept working, because they never format a stack.
Reproduction
Trigger project on runtime: node-22 with ai@7.0.66 and @ai-sdk/anthropic@4.0.39, plus npm overrides: { "esbuild": "0.25.0" }. Build through loadConfig -> buildWorker, then decode each emitted .map and check that every source index is below sources.length:
- esbuild 0.25.0: 42 of 44 maps valid
- esbuild 0.23.1: 44 of 44
- esbuild 0.28.2: 44 of 44
Suggested changes
- Warn or fail when the resolved
esbuild version falls outside the CLI's declared range. This alone would have surfaced the problem on the first deploy.
- Validate emitted sourcemaps before imaging. Checking index bounds is cheap, and the corruption is otherwise invisible until something throws.
- Guard
.stack access in error reporting so a malformed map cannot replace the error being reported.
Happy to open a PR for 1 or 3.
What happened
trigger.dev@4.5.11declaresesbuild ^0.23.0. Our repo had a root-level npmoverridesentry pinningesbuildto0.25.0, added for GHSA-67mh-4wv8-2f99. npm honours the override, so the CLI bundled with 0.25.0 without warning.esbuild 0.25.0 has an out-of-bounds source-index regression, fixed in 0.25.1, that drops input
sourcesentries while keeping the mapping indices. Two of our deployed chunks came out internally inconsistent:trigger/slack-attention-agent.mjs.map: 6sources, mappings referencing index 37aichunk: 171sources, mappings referencing index 200Impact
The worker installs
source-map-supportglobally (entryPoints/managed-run-worker.js). Once a stack contained a frame from either chunk,originalPositionForthrewError: No element indexed by 6.recordSpanException(otel/utils.ts) and the AI SDK's default error handler (console.error(error)) both read.stackwithout a guard, so that exception replaced the error being reported.Every
chat.agentturn failed for a week withNo element indexed by 6. The original error never surfaced anywhere, including instreamText'sonError, which received the substituted message instead. Scheduled tasks on the same deployment kept working, because they never format a stack.Reproduction
Trigger project on
runtime: node-22withai@7.0.66and@ai-sdk/anthropic@4.0.39, plus npmoverrides: { "esbuild": "0.25.0" }. Build throughloadConfig->buildWorker, then decode each emitted.mapand check that every source index is belowsources.length:Suggested changes
esbuildversion falls outside the CLI's declared range. This alone would have surfaced the problem on the first deploy..stackaccess in error reporting so a malformed map cannot replace the error being reported.Happy to open a PR for 1 or 3.