feat(opentelemetry) add @temporalio/interceptors-opentelemetry-v2 by chris-olszewski · Pull Request #1951 · temporalio/sdk-typescript

chris-olszewski · 2026-02-26T01:34:24Z

What was changed

Add a package to provide interceptors that support OpenTelemetry v2.

First commit is a straight copy of the v1 with package bumps and the necessary changes the came along with those bumps.

Note: Histories created with the @temporalio/interceptors-opentelemetry will not be compatible with @temporalio/interceptors-opentelemetry and vice-versa. The crux of the issue is that OpenTelemetry changed their usage of Math.random(). The random number generator was shared by OpenTelemetry for generating span ids as well as the uuid function which is used for generating child workflow ids. This can cause NDE. To prevent future breakages from changes to Math.random usage, we now provide an IdGenerator to OpenTelemetry that uses its own random number generator. This doesn't offer a huge amount of value as we are still vulnerable to changes to the amount of calls to Math.random outside of id creation, but it does offer protection if the number of ids created changes.

Due to histories already being incompatible, I removed the yield point injections from the interceptors to have a cleaner starting point.

Why?

This was done in a separate package to allow us to support both v1 and v2 without forcing users to upgrade.

Checklist

Closes [Feature Request] Add support for opentelemetry v2 #1658
How was this tested:
Copied over relevant tests and added an additional test to verify that replaying workflow history that has uuid call doesn't trigger NDE in the future.
Any docs updates needed?

grant0417 · 2026-03-26T01:55:13Z

Since you are making a breaking v2 version, could you also align the spanProcessor with how it works in the @opentelemetry/sdk-node package.

The spanProcessor arg is deprecated in favor of spanProcessors which is an array of processors. This would allow using the same arg to both the temporal OpenTelemetryPlugin and NodeSDK.

Example:

const resource = resourceFromAttributes({ [ATTR_SERVICE_NAME]: "temporal-worker" });
const spanProcessors = [new SpanProcessor1(), new SpanProcessor2()];

// exact same args
const sdk = new NodeSDK({ resource, spanProcessors });
const plugin = OpenTelemetryPlugin({ resource, spanProcessors });

mjameswh · 2026-04-21T12:10:27Z

+      clientInterceptors: {
+        workflow: [new OpenTelemetryWorkflowClientInterceptor(interceptorOptions)],
+      },
+      workerInterceptors: {


We need to add nexus interceptors

mjameswh · 2026-04-21T12:15:17Z

+export * from './worker';
+export {
+  OpenTelemetryWorkflowClientInterceptor,
+  /** deprecated: Use OpenTelemetryWorkflowClientInterceptor instead */


You can get rid of that legacy thing.

mjameswh · 2026-04-21T12:28:29Z

+ *
+ * @experimental Plugins is an experimental feature; APIs may change without notice.
+ */
+export class OpenTelemetryPlugin extends SimplePlugin {


Are we not injecting bundler options?

Btw, we now have a preloadedModules bundler option, which may help reduce the overhead associated with per-workflow loading of the OpenTelemetry library.

mjameswh · 2026-04-21T12:29:35Z

+ * @module
+ */
+export { inWorkflowContext, proxySinks, workflowInfo, AsyncLocalStorage, ContinueAsNew } from '@temporalio/workflow';
+export { alea, type RNG } from '@temporalio/workflow/lib/alea';


Use the new random streams api once it has landed.

mjameswh · 2026-04-21T12:42:42Z

@@ -0,0 +1,54 @@
+import type { IdGenerator } from '@opentelemetry/sdk-trace-base';
+import { alea, type RNG } from './workflow-imports';


Use the new Random Streams API, once it has landed.

semgrep-managed-scans · 2026-05-18T13:45:17Z

+      const otel = new opentelemetry.NodeSDK({
+        resource: staticResource,
+        traceExporter: wrappedExporter,
+      });


High severity vulnerability may affect your project—review required:
Line 637 lists a dependency (@opentelemetry/sdk-node) with a known High severity vulnerability.

ℹ️ Why this matters

Affected versions of @opentelemetry/auto-instrumentations-node, @opentelemetry/exporter-prometheus, and @opentelemetry/sdk-node are vulnerable to Improper Handling of Exceptional Conditions. An attacker on any network that can reach the OpenTelemetry Prometheus exporter metrics port (default 0.0.0.0:9464) can crash the Node.js process by sending a single malformed HTTP request: the exporter's request handler calls new URL(request.url, baseUrl) without a try/catch, so an "Invalid URL" TypeError propagates out of the request callback and terminates the process — an unauthenticated remote denial of service. The vulnerable HTTP server starts either when the application directly constructs PrometheusExporter from @opentelemetry/exporter-prometheus, or when it runs @opentelemetry/sdk-node / @opentelemetry/auto-instrumentations-node/register with the OTEL_METRICS_EXPORTER environment variable set to include prometheus, in which case the SDK instantiates PrometheusExporter internally on the user's behalf.

References: GHSA

To resolve this comment:
Check if you set the OTEL_METRICS_EXPORTER environment variable to include prometheus when relying on auto-configuration via @opentelemetry/sdk-node or @opentelemetry/auto-instrumentations-node/register.

If you're affected, upgrade this dependency to at least version 0.217.0 at pnpm-lock.yaml.

If you're not affected, comment /fp we don't use this [condition]

💬 Ignore this finding

To ignore this, reply with:

/fp <comment> for false positive

/ar <comment> for acceptable risk

/other <comment> for all other reasons

_{You can view more details on this finding in the Semgrep AppSec Platform here.}

semgrep-managed-scans · 2026-05-18T13:45:19Z

+      const otel = new opentelemetry.NodeSDK({
+        resource: staticResource,
+        traceExporter: exporter,
+      });


High severity vulnerability may affect your project—review required:
Line 289 lists a dependency (@opentelemetry/sdk-node) with a known High severity vulnerability.

ℹ️ Why this matters

Affected versions of @opentelemetry/auto-instrumentations-node, @opentelemetry/exporter-prometheus, and @opentelemetry/sdk-node are vulnerable to Improper Handling of Exceptional Conditions. An attacker on any network that can reach the OpenTelemetry Prometheus exporter metrics port (default 0.0.0.0:9464) can crash the Node.js process by sending a single malformed HTTP request: the exporter's request handler calls new URL(request.url, baseUrl) without a try/catch, so an "Invalid URL" TypeError propagates out of the request callback and terminates the process — an unauthenticated remote denial of service. The vulnerable HTTP server starts either when the application directly constructs PrometheusExporter from @opentelemetry/exporter-prometheus, or when it runs @opentelemetry/sdk-node / @opentelemetry/auto-instrumentations-node/register with the OTEL_METRICS_EXPORTER environment variable set to include prometheus, in which case the SDK instantiates PrometheusExporter internally on the user's behalf.

References: GHSA

To resolve this comment:
Check if you set the OTEL_METRICS_EXPORTER environment variable to include prometheus when relying on auto-configuration via @opentelemetry/sdk-node or @opentelemetry/auto-instrumentations-node/register.

If you're affected, upgrade this dependency to at least version 0.217.0 at pnpm-lock.yaml.

If you're not affected, comment /fp we don't use this [condition]

💬 Ignore this finding

To ignore this, reply with:

/fp <comment> for false positive

/ar <comment> for acceptable risk

/other <comment> for all other reasons

_{You can view more details on this finding in the Semgrep AppSec Platform here.}

semgrep-managed-scans · 2026-05-18T13:45:20Z

+      const otel = new opentelemetry.NodeSDK({
+        resource: staticResource,
+        traceExporter,
+      });


High severity vulnerability may affect your project—review required:
Line 135 lists a dependency (@opentelemetry/sdk-node) with a known High severity vulnerability.

ℹ️ Why this matters

Affected versions of @opentelemetry/auto-instrumentations-node, @opentelemetry/exporter-prometheus, and @opentelemetry/sdk-node are vulnerable to Improper Handling of Exceptional Conditions. An attacker on any network that can reach the OpenTelemetry Prometheus exporter metrics port (default 0.0.0.0:9464) can crash the Node.js process by sending a single malformed HTTP request: the exporter's request handler calls new URL(request.url, baseUrl) without a try/catch, so an "Invalid URL" TypeError propagates out of the request callback and terminates the process — an unauthenticated remote denial of service. The vulnerable HTTP server starts either when the application directly constructs PrometheusExporter from @opentelemetry/exporter-prometheus, or when it runs @opentelemetry/sdk-node / @opentelemetry/auto-instrumentations-node/register with the OTEL_METRICS_EXPORTER environment variable set to include prometheus, in which case the SDK instantiates PrometheusExporter internally on the user's behalf.

References: GHSA

To resolve this comment:
Check if you set the OTEL_METRICS_EXPORTER environment variable to include prometheus when relying on auto-configuration via @opentelemetry/sdk-node or @opentelemetry/auto-instrumentations-node/register.

If you're affected, upgrade this dependency to at least version 0.217.0 at pnpm-lock.yaml.

If you're not affected, comment /fp we don't use this [condition]

💬 Ignore this finding

To ignore this, reply with:

/fp <comment> for false positive

/ar <comment> for acceptable risk

/other <comment> for all other reasons

_{You can view more details on this finding in the Semgrep AppSec Platform here.}

chris-olszewski force-pushed the olszewski/feat_otel_v2 branch from 3039377 to 99e880b Compare February 26, 2026 01:40

andyfleming-shopify mentioned this pull request Mar 4, 2026

[HOLD] chore(otel): Migrate from v1 to v2 #1844

Open

chris-olszewski marked this pull request as ready for review March 10, 2026 14:53

chris-olszewski requested a review from a team as a code owner March 10, 2026 14:53

mjameswh reviewed Apr 21, 2026

View reviewed changes

JackTreble mentioned this pull request Apr 23, 2026

[HOLD] chore: support opentelemetry v2 #1741

Closed

chris-olszewski force-pushed the olszewski/break_up_build branch 4 times, most recently from ebccf95 to 381fbbb Compare May 11, 2026 18:04

Base automatically changed from olszewski/break_up_build to main May 12, 2026 18:01

chris-olszewski added 4 commits May 14, 2026 12:14

feat(opentelemetry): add otel v2 package

38dba4c

fix(otel-v2): provide id generator

febfc2a

chore: add test for id generator and remove v1 flags

6cf53a1

fix merge conflicts

0642b14

chris-olszewski marked this pull request as draft May 18, 2026 13:41

chris-olszewski force-pushed the olszewski/feat_otel_v2 branch from 054f66b to 0642b14 Compare May 18, 2026 13:41

semgrep-managed-scans Bot reviewed May 18, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat(opentelemetry) add @temporalio/interceptors-opentelemetry-v2#1951

feat(opentelemetry) add @temporalio/interceptors-opentelemetry-v2#1951
chris-olszewski wants to merge 4 commits into
mainfrom
olszewski/feat_otel_v2

chris-olszewski commented Feb 26, 2026 •

edited

Loading

Uh oh!

grant0417 commented Mar 26, 2026

Uh oh!

mjameswh Apr 21, 2026

Uh oh!

mjameswh Apr 21, 2026

Uh oh!

mjameswh Apr 21, 2026

Uh oh!

mjameswh Apr 21, 2026

Uh oh!

mjameswh Apr 21, 2026

Uh oh!

semgrep-managed-scans Bot May 18, 2026

Uh oh!

semgrep-managed-scans Bot May 18, 2026

Uh oh!

semgrep-managed-scans Bot May 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

		@@ -0,0 +1,54 @@
		import type { IdGenerator } from '@opentelemetry/sdk-trace-base';
		import { alea, type RNG } from './workflow-imports';

Conversation

chris-olszewski commented Feb 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What was changed

Why?

Checklist

Uh oh!

grant0417 commented Mar 26, 2026

Uh oh!

mjameswh Apr 21, 2026

Choose a reason for hiding this comment

Uh oh!

mjameswh Apr 21, 2026

Choose a reason for hiding this comment

Uh oh!

mjameswh Apr 21, 2026

Choose a reason for hiding this comment

Uh oh!

mjameswh Apr 21, 2026

Choose a reason for hiding this comment

Uh oh!

mjameswh Apr 21, 2026

Choose a reason for hiding this comment

Uh oh!

semgrep-managed-scans Bot May 18, 2026

Choose a reason for hiding this comment

Uh oh!

semgrep-managed-scans Bot May 18, 2026

Choose a reason for hiding this comment

Uh oh!

semgrep-managed-scans Bot May 18, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

chris-olszewski commented Feb 26, 2026 •

edited

Loading