bug(typescript): agentcore deploy sets up no ADOT/OTel instrumentation for TypeScript agents, silently dropping all 3p telemetry

schema-mapper.ts、TypeScript の Dockerfile、2 つの TypeScript テンプレート package.json ファイル、および src/lib/packaging/node.ts の CodeZip パスから始めます。既存の Dockerfile レンダリングテストを実行し、指定された TypeScript のカバレッジを追加します。container と CodeZip の TypeScript エージェントが文書化されたインストルメンテーションパスを設定し、#1270 の Runtime sidecar 依存関係と併せてテレメトリーの動作が検証されれば完了です。

Description

agentcore deploy does not set up any OpenTelemetry / ADOT instrumentation for TypeScript agents. Python agents get zero-code instrumentation via opentelemetry-instrument; TypeScript agents get nothing at any layer. As a result, spans emitted by any 3p instrumentation library (Strands, Vercel AI SDK, or a user's own @opentelemetry/api calls) are silently dropped, and nothing appears in CloudWatch / X-Ray Transaction Search.

This is a regression, not a never-implemented feature — the wiring existed and was removed (see below).

Steps to Reproduce

1. agentcore create --language TypeScript --sdk Strands --protocol HTTP --build Container
2. agentcore deploy
3. Invoke the deployed agent so it produces LLM/tool calls
4. Open CloudWatch → Application Signals / X-Ray Transaction Search and look for traces from the agent

Also observable statically, without deploying:

• Generated Dockerfile ends in CMD ["npx", "tsx", "main.ts"] — no instrumentation wrapper
• Generated package.json contains no OTel SDK, only the no-op @opentelemetry/api

Expected Behavior

TypeScript agents get zero-code ADOT instrumentation at parity with Python, so that 3p instrumentation libraries emitting via @opentelemetry/api export to the collector and show up in CloudWatch without any application code changes.

Actual Behavior

No instrumentation is configured. Three independent gaps, each sufficient on its own to produce zero telemetry:

1. enableOtel is hardcoded off for TypeScript — src/cli/operations/agent/generate/schema-mapper.ts:284

const enableOtel = !isMcp && config.language !== 'TypeScript';

2. The TypeScript Dockerfile has no instrumentation branch at all — src/assets/container/typescript/Dockerfile:25

CMD ["npx", "tsx", "main.ts"]

Compare src/assets/container/python/Dockerfile:40-44, which does branch:

{{#if enableOtel}}
CMD ["opentelemetry-instrument", "python", "-m", "{{entrypoint}}"]
{{else}}
CMD ["python", "-m", "{{entrypoint}}"]
{{/if}}

Because no {{#if enableOtel}} block exists in the TS Dockerfile, setting instrumentation.enableOtel: true on a TypeScript agent has no effect — there is nothing for it to render. The schema at src/schema/schemas/agent-env.ts:194 defaults it to true and documents it as "the runtime entrypoint is wrapped with opentelemetry-instrument", which is silently untrue for TypeScript.

3. No OTel SDK dependency or bootstrap in the TS templates. src/assets/typescript/http/strands/base/package.json carries only @opentelemetry/api — the no-op API surface, which discards all spans unless a global provider is registered. src/assets/typescript/http/vercelai/base/package.json has no OTel dependency at all. Neither template registers a provider.

The CodeZip path is affected too: TS CodeZip builds are bundled with esbuild (src/lib/packaging/node.ts:95) and have no Dockerfile to hook, so they need the instrumentation applied via runtime env vars rather than a CMD change.

Origin of the regression

Commit 580cd10b — "fix(templates): remove OTEL, session storage, and gateway from TS templates", merged in #981 (2026-05-14) — removed the working implementation:

• deleted src/assets/typescript/http/strands/base/otel-register.ts and the vercelai equivalent, which registered a NodeTracerProvider + MeterProvider with OTLP exporters
• removed import './otel-register.js'; from both main.ts files
• removed 7 @opentelemetry/* dependencies from both package.json files
• flipped schema-mapper.ts to exclude TypeScript

The OTel removal was one commit inside a broader TS template/streaming PR, so it isn't visible from the PR title.

Interaction with #1270 (important)

Fixing the CLI alone is not sufficient to get traces into CloudWatch. Per #1270, AgentCore Runtime starts the ADOT collector sidecar on localhost:4318 only when it detects opentelemetry-instrument in the container entrypoint, which is Python-specific. A TypeScript entrypoint never matches, so nothing listens on :4318 and OTLP export fails silently even with a correctly registered SDK.

These two need to land together for end-to-end telemetry. Adopting a --require-based ADOT entrypoint (below) may also give the Runtime a detectable signal for starting the sidecar, which is worth confirming with the Runtime team.

Suggested fix

ADOT for Node exists and is current: @aws/[email protected]. True zero-code parity with Python is a NODE_OPTIONS=--require @aws/aws-distro-opentelemetry-node-autoinstrumentation/register entrypoint — a single dependency and no hand-maintained otel-register.ts, unlike the reverted implementation.

Touch points:

• src/cli/operations/agent/generate/schema-mapper.ts:284 — stop excluding TypeScript
• src/assets/container/typescript/Dockerfile — add the {{#if enableOtel}} branch
• both TS template package.json files — add the ADOT distro dependency
• TS CodeZip path — set the instrumentation env vars on the runtime (no Dockerfile to hook)
• src/assets/__tests__/dockerfile-render.test.ts — currently only exercises the Python Dockerfile; add TS coverage so this cannot silently regress again

CLI Version

0.25.0 (repo package.json, at commit 8fba8160)