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: https://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
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
externalTraceIdhere: https://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
Additional information
No response