Repository navigation
bug: trace id shared between different runs triggered by cron in DEV env #4313
Description
Provide environment information
System:
OS: macOS 26.2
CPU: (10) arm64 Apple M1 Max
Memory: 2.03 GB / 32.00 GB
Shell: 5.9 - /bin/zsh
Binaries:
Node: 24.9.0 - /Users/awinn/.node_versions/bin/node
Yarn: 4.17.0 - /Users/awinn/projects/work/cal/node_modules/.bin/yarn
npm: 11.6.0 - /Users/awinn/.node_versions/bin/npm
Deno: 2.8.0 - /opt/homebrew/bin/deno
Describe the bug
I am in running on a development branch and have multiple tasks scheduled to run with cron schedules.
After enabling tracing in the environment I noticed traces in grafana that had two "Attempt 1" spans for different tasks.
I was able to inspect the otel processors at runtime during task execution and log the externalTraceId here: http://github.com/triggerdotdev/trigger.dev/pull/3768/changes#diff-ce510b575f0568e5e9854cedbca289205f363324a89085ae9b668c3cc334cd93R437 which is set once when the app starts up. That generated trace id was used to replace the existing trace IDs of the spans for both tasks.
I don't think it ever makes sense to replace the trace IDs of multiple spans with one global persistent value like this. If a parent trace context is not found it's better for each attempt to become the root span of it's own trace.
Reproduction repo
na
To reproduce
- create two distinct tasks the run at the same time via CRON.
- configure otel export to any compatible service
- start trigger.dev in development and observe the traces your provider shows for those tasks
Additional information
No response
Activity
dubeyharshit0605 commentedon Jul 22, 2026
Hi, I’d like to work on this. I’ll first reproduce it with two cron tasks, trace where the external context is reused, and add a regression test ensuring independent runs get distinct root traces while valid propagated parent contexts still work.
Is this available for an external contribution? If yes, I’ll submit the required Vouch Request before starting.