fix(deps): update opentelemetry-js monorepo

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
@opentelemetry/api (source)	1.9.0 → 1.9.1
@opentelemetry/api-logs (source)	^0.54.0 → ^0.219.0
@opentelemetry/exporter-logs-otlp-proto (source)	^0.54.0 → ^0.219.0
@opentelemetry/exporter-trace-otlp-proto (source)	^0.54.0 → ^0.219.0
@opentelemetry/otlp-exporter-base (source)	^0.208.0 → ^0.219.0
@opentelemetry/sdk-logs (source)	^0.54.0 → ^0.219.0
@opentelemetry/semantic-conventions (source)	1.38.0 → 1.41.1

---

Release Notes

open-telemetry/opentelemetry-js (@​opentelemetry/api)

v1.9.1

Compare Source

🐛 (Bug Fix)

• fix: avoid grpc types dependency #​3551 @​flarna
• fix(otlp-proto-exporter-base): Match Accept header with Content-Type in the proto exporter
  #​3562 @​scheler
• fix: include tracestate in export #​3569 @​flarna

🏠 (Internal)

• chore: fix cross project links and missing implicitly exported types #​3533 @​legendecas
• feat(sdk-metrics): add exponential histogram mapping functions #​3504 @​mwear

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • "before 6am on the first day of the month"
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[changeset-bot]

⚠️ No Changeset found

Latest commit: fa4f81f

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

[devin-ai-integration]

Devin Review found 1 potential issue.

View 2 additional findings in Devin Review.

[devin-ai-integration]

🔴 Trace exporter version mismatch causes incompatible span processing at runtime

The experimental OpenTelemetry packages are updated to 0.219.x (agents/package.json:61-68) without updating the stable packages (sdk-trace-base, sdk-trace-node, resources) from 1.x to the required 2.x, so the trace exporter may fail to serialize spans correctly.

Impact: Traces exported to LiveKit Cloud observability may be malformed or silently dropped because the exporter expects 2.x span structures but receives 1.x spans.

Version compatibility matrix violation between OTel experimental and stable packages

The OpenTelemetry JS ecosystem requires version-aligned groups:

• Experimental 0.54.x works with stable 1.x
• Experimental 0.219.x works with stable 2.x

The lockfile confirms the mismatch:

• @opentelemetry/exporter-trace-otlp-proto@0.219.0 depends on @opentelemetry/sdk-trace-base@2.8.0 and @opentelemetry/resources@2.8.0
• @opentelemetry/sdk-trace-node@1.30.1 (from the unchanged ^1.28.0 specifier) depends on @opentelemetry/sdk-trace-base@1.30.1

In agents/src/telemetry/traces.ts:256-265, the code creates an OTLPTraceExporter (0.219.0, internally linked to sdk-trace-base@2.8.0) and passes it to BatchSpanProcessor from sdk-trace-node@1.30.1. At runtime:

1. NodeTracerProvider (1.x) creates spans as ReadableSpan from sdk-trace-base@1.30.1
2. BatchSpanProcessor (1.x) passes those spans to OTLPTraceExporter.export()
3. The exporter's otlp-transformer@0.219.0 serializes spans expecting ReadableSpan from sdk-trace-base@2.8.0

Between major versions, ReadableSpan had breaking changes (resource type changed from Resource class to IResource interface, time representation changes). The transformer may access properties that are missing or structured differently on 1.x spans.

The fix should also update:

• @opentelemetry/sdk-trace-base to ^2.8.0
• @opentelemetry/sdk-trace-node to ^2.8.0
• @opentelemetry/resources to ^2.8.0

---

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

[devin-ai-integration]

Devin Review found 7 new potential issues.

[devin-ai-integration]

🚩 examples/package.json still uses old 0.54.x OpenTelemetry versions

The examples/package.json still declares @opentelemetry/api-logs: ^0.54.0, @opentelemetry/exporter-logs-otlp-http: ^0.54.0, @opentelemetry/exporter-trace-otlp-http: ^0.54.0, @opentelemetry/otlp-exporter-base: ^0.54.0, and @opentelemetry/sdk-logs: ^0.54.0. The lockfile confirms that the examples workspace resolves these to 0.54.2 while the agents workspace resolves to 0.218.0. This means two different versions of these packages coexist in the monorepo. While examples is a private package and not published, this inconsistency could lead to confusing behavior when debugging telemetry in example agents. It may be worth updating examples to match.

---

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

[devin-ai-integration]

🚩 CompressionAlgorithm import may have changed in otlp-exporter-base 0.218.0

The code at agents/src/telemetry/traces.ts:18 imports CompressionAlgorithm from @opentelemetry/otlp-exporter-base. The OpenTelemetry v2 line reorganized some exports. If CompressionAlgorithm was moved or renamed in 0.218.0, this would cause a build failure. This should be caught by TypeScript compilation in CI, so it's not reported as a bug, but it's worth verifying that pnpm build passes after this change.

---

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

[devin-ai-integration]

🚩 Mixed OpenTelemetry SDK major versions (1.x trace SDK + 0.218.0 exporters)

The PR updates exporter packages to 0.218.0 (which internally depends on @opentelemetry/sdk-trace-base@2.7.1) while keeping @opentelemetry/sdk-trace-node and @opentelemetry/sdk-trace-base at ^1.28.0 (resolved to 1.30.1). This creates two copies of sdk-trace-base in the dependency tree (1.30.1 and 2.7.1). In agents/src/telemetry/traces.ts:253-261, the OTLPTraceExporter from exporter-trace-otlp-proto@0.218.0 is passed to a BatchSpanProcessor from sdk-trace-node@1.30.1. If the SpanExporter interface changed between sdk-trace-base 1.x and 2.x, this could cause runtime issues where spans fail to export silently. The lockfile resolves successfully but doesn't guarantee interface-level compatibility across these major version boundaries.

---

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

[devin-ai-integration]

🚩 Stable OTel packages not bumped alongside experimental ones

Only the experimental (0.x) OpenTelemetry packages were bumped, while the stable ones (@opentelemetry/resources@^1.28.0, @opentelemetry/sdk-trace-base@^1.28.0, @opentelemetry/sdk-trace-node@^1.28.0, @opentelemetry/semantic-conventions@^1.28.0) remain on 1.x. The OpenTelemetry JS monorepo releases stable and experimental packages in lockstep — 0.217.0 experimental packages correspond to 2.x stable packages. Not bumping the stable packages to 2.x may leave the project in an inconsistent state where the exporter/logger packages expect 2.x internal APIs but the tracer provider uses 1.x. Consider bumping all OTel packages together for consistency.

---

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

[devin-ai-integration]

🚩 instrumentation-pino still resolves to old api-logs version

The @opentelemetry/instrumentation-pino@0.43.0 package (specified in agents/package.json:65) still resolves to @opentelemetry/api-logs@0.54.2 according to the lockfile, while the direct dependency @opentelemetry/api-logs is now ^0.219.0. This means two different versions of api-logs are installed. Since instrumentation-pino uses its own copy internally for creating log records, and the agents code imports SeverityNumber from the top-level api-logs@0.219.0, there could be subtle enum value mismatches if SeverityNumber changed between versions. Worth verifying that the instrumentation-pino package is also compatible with the 0.219.x ecosystem.

---

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

[devin-ai-integration]

🚩 sdk-logs 0.218.0 LogRecordProcessor interface appears backward compatible

The @opentelemetry/sdk-logs bump from ^0.54.0 to ^0.218.0 changes the version used by agents/src/telemetry/logging.ts:6 which imports LogRecord and LogRecordProcessor. The custom processors (MetadataLogProcessor and ExtraDetailsProcessor) implement onEmit(logRecord), shutdown(), and forceFlush(). In the 2.x SDK era, onEmit gained an optional context parameter, which is backward compatible with existing implementations that omit it. However, this should be verified — if the LogRecordProcessor interface in 0.218.0 made context a required parameter, these custom processors would fail at runtime (TypeScript structural typing might still allow it).

---

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

[devin-ai-integration]

🚩 Large version jump for api-logs, sdk-logs, and exporter packages (0.54.x → 0.214.x)

Four packages jump from 0.54.x to 0.214.x (api-logs, sdk-logs, exporter-logs-otlp-proto, exporter-trace-otlp-proto). This is due to the OpenTelemetry JS project's versioning realignment (experimental packages went from 0.5x to 0.200+ to match stable package versions). While the lockfile resolves and the key APIs used in the codebase (SeverityNumber enum values from api-logs, LogRecord/LogRecordProcessor from sdk-logs) are standardized OTLP types unlikely to have changed, this is a major jump spanning many releases. A full build verification (pnpm build) should be confirmed to pass, as well as runtime testing of the telemetry/tracing path (e.g., cloud tracer setup at agents/src/telemetry/traces.ts:213-280 and log export at agents/src/telemetry/otel_http_exporter.ts).

---

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