feat: custom span processors in telementry options

[Shaik-Sirajuddin]

Closes #2979

✅ Checklist

• I have followed every step in the contributing guide
• The PR title follows the convention.
• I ran and tested the code works

---

Testing

1.define a custom otel processor with logging

export class LogSpanProcessor implements SpanProcessor {
  forceFlush(): Promise<void> {
    return Promise.resolve();
  }
  onStart(span: Span, parentContext: Context): void {
    console.log("Data from details start called ");
  }
  onEnd(span: ReadableSpan): void {}
  shutdown(): Promise<void> {
    return Promise.resolve();
  }
}

2. pass an instance of processor to config
3. run a task from ui
4. verify the logs from processor are present in terminal

Changelog

[Short description of what has changed]
telementry options now support passing custom otel span processors

Screenshots

[Screenshots]

💯

[changeset-bot]

⚠️ No Changeset found

Latest commit: 3145c8e

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[github-actions]

Hi @Shaik-Sirajuddin, thanks for your interest in contributing!

This project requires that pull request authors are vouched, and you are not in the list of vouched users.

This PR will be closed automatically. See https://github.com/triggerdotdev/trigger.dev/blob/main/CONTRIBUTING.md for more details.

[coderabbitai]

Caution

Review failed

The pull request is closed.

Walkthrough

This pull request introduces optional custom span processor configuration to the OpenTelemetry telemetry setup. The changes add a new spanProcessors property to TriggerConfig.telemetry that accepts an array of SpanProcessor instances. The SpanProcessor type is imported from @opentelemetry/sdk-trace-base, the property is threaded through the configuration, and the TracingSDK implementation is updated to include external span processors in the processing chain before default processors. Two worker entry points are updated to pass the configured span processors to the SDK.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between ba320a4 and 3145c8e.

📒 Files selected for processing (4)

• packages/cli-v3/src/entryPoints/dev-run-worker.ts
• packages/cli-v3/src/entryPoints/managed-run-worker.ts
• packages/core/src/v3/config.ts
• packages/core/src/v3/otel/tracingSDK.ts

_{✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.}

Tip

Issue Planner is now in beta. Read the docs and try it out! Share your feedback on Discord.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[devin-ai-integration]

Devin Review found 2 potential issues.

View 2 additional findings in Devin Review.

[devin-ai-integration]

🚩 managed-run-worker doesn't check telemetry.instrumentations (pre-existing inconsistency)

In dev-run-worker.ts:207, instrumentations are resolved with config.telemetry?.instrumentations ?? config.instrumentations ?? [], properly supporting both the new telemetry.instrumentations path and the deprecated top-level instrumentations field.

However, managed-run-worker.ts:186 only uses config.instrumentations ?? [], ignoring config.telemetry?.instrumentations entirely. This means users who configure instrumentations under the telemetry key (as the deprecation notice on config.ts:86-87 suggests) will have them silently ignored in managed/production runs while working fine in dev. This is a pre-existing issue not introduced by this PR, but the PR author may want to fix it alongside this change for consistency.

(Refers to line 186)

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🚩 Custom span processors' onStart won't see task context attributes

Custom span processors are pushed into the array before TaskContextSpanProcessor at packages/core/src/v3/otel/tracingSDK.ts:130-148. The NodeTracerProvider calls each processor's onStart in order, so custom processors' onStart will execute before TaskContextSpanProcessor.onStart adds task context metadata attributes (see packages/core/src/v3/taskContext/otelProcessors.ts:18-31 where span.setAttributes(...) is called).

However, since attributes are mutated on the shared span object, custom processors' onEnd will see the task context attributes (they were already set during the onStart phase). This is likely acceptable for most use cases (the PR's example LogSpanProcessor only logs in onStart and doesn't read attributes), but users writing processors that need task context in onStart would be surprised. The comment on line 125 says this ordering is intentional.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[ericallam]

We're going to be changing how this whole system works shortly which will allow people to define their own custom otel stack and we'll provide a span/log/metric processor that sends them to the trigger.dev instance.