Subprocess MeterProvider does not honour OTEL_RESOURCE_ATTRIBUTES (only TracerProvider does)

[biz-tiwo]

Summary

The Copilot CLI subprocess (spawned by github-copilot-sdk v0.2.2) correctly applies OTEL_RESOURCE_ATTRIBUTES to spans but does not apply them to metrics emitted from the same process. This makes per-run / per-tenant attribution impossible for metric-backed dashboards.

Reproduction

1. Set custom resource attributes before spawning the SDK / starting the CLI:

   export OTEL_SERVICE_NAME=workflow-skeleton
   export OTEL_RESOURCE_ATTRIBUTES=workflow.run_kind=resume
   export OTEL_EXPORTER_OTLP_ENDPOINT=https://otlp.eu01.nr-data.net
   export OTEL_EXPORTER_OTLP_HEADERS="api-key=..."

2. Run any workflow that produces both spans and metrics from the subprocess (chat, execute_tool, etc.).
3. Query the backend for spans and metrics where otel.library.name = 'github.copilot'.

Observed (New Relic NRQL, EU)

Spans — Resource attribute is present:

FROM Span SELECT count(*) WHERE otel.library.name = 'github.copilot'
  FACET workflow.run_kind SINCE 6 hours ago
-- => resume: 41

Metrics — Resource attribute is missing:

FROM Metric SELECT keyset() WHERE metricName = 'gen_ai.client.token.usage' SINCE 6 hours ago
-- => keys: service.name, service.version, gen_ai.*, otel.library.name, ...
--    NO workflow.run_kind

FROM Metric SELECT count(*) WHERE metricName = 'gen_ai.client.token.usage' SINCE 24 hours ago
  FACET workflow.run_kind
-- => only NULL bucket

service.name (set via OTEL_SERVICE_NAME) does land on metrics, suggesting the MeterProvider is reading the dedicated env var but not the generic OTEL_RESOURCE_ATTRIBUTES.

Affected Metric Names

All metrics emitted by the subprocess with otel.library.name = 'github.copilot', including:

• gen_ai.client.token.usage
• gen_ai.client.operation.duration
• github.copilot.tool.call.count
• github.copilot.tool.call.duration

Expected

The subprocess MeterProvider should be initialized with the same Resource as the TracerProvider — typically by calling Resource.default().merge(Resource.fromEnvironment()) (or the equivalent in whichever SDK powers the binary), so that any OTEL_RESOURCE_ATTRIBUTES value is also applied to emitted metrics.

Impact

Downstream observability tools (dashboards, alerts, billing attribution) cannot filter or group LLM / tool-call metrics by per-invocation context (tenant, workflow run, run kind, environment, etc.). Spans can be filtered correctly, but metric-backed widgets — which are required for cardinality-friendly aggregations like rate, percentile, or distribution — return only the global / NULL bucket.

Environment

• github-copilot-sdk==0.2.2
• Python 3.13
• macOS arm64
• Bundled CLI binary at .venv/lib/python3.13/site-packages/copilot/bin/copilot (Mach-O arm64, packed)

[github-actions]

Bug Investigation Summary

Thanks for the detailed report and NRQL queries — this is a genuine bug. Here's what I found:

What I investigated

• python/copilot/client.py — Environment variable handling when spawning the CLI subprocess (_start_cli_server, lines 2582–2613)
• go/types.go, python/copilot/client.py — TelemetryConfig struct/class and how it maps fields to CLI env vars
• nodejs/src/telemetry.ts, python/copilot/_telemetry.py, dotnet/src/Telemetry.cs, go/telemetry.go — SDK-side telemetry helpers (trace context propagation only — no OTEL provider setup in the SDKs themselves)
• python/e2e/test_telemetry_e2e.py and related E2E tests — Existing telemetry test coverage

What I found

The SDK client libraries are not the root cause. When spawning the CLI subprocess, the Python SDK correctly passes OTEL_RESOURCE_ATTRIBUTES (and all other inherited env vars) through to the subprocess when env is None (the default — it copies os.environ). The same is true for the Node.js, Go, and .NET SDKs.

The bug is in the CLI binary's OTEL initialization code. Specifically:

• The CLI binary's TracerProvider is initialized with a Resource that calls the equivalent of Resource.default().merge(Resource.fromEnvironment()), so it picks up both OTEL_SERVICE_NAME and OTEL_RESOURCE_ATTRIBUTES.
• The CLI binary's MeterProvider is initialized with a Resource that only picks up OTEL_SERVICE_NAME (likely via a dedicated constant or Resource.default() without the environment merge step). The Resource.fromEnvironment() call — which would read OTEL_RESOURCE_ATTRIBUTES — is absent from the MeterProvider initialization path.

This explains the exact asymmetry you observed: service.name reaches metrics (because it's read from OTEL_SERVICE_NAME via a dedicated path), but arbitrary attributes like workflow.run_kind set through OTEL_RESOURCE_ATTRIBUTES do not.

Why this is a bug

The OpenTelemetry spec requires that OTEL_RESOURCE_ATTRIBUTES be applied to all signal pipelines (traces, metrics, and logs) uniformly. The asymmetric behavior between the TracerProvider and MeterProvider is not intentional design — it is a defect in the CLI binary's OTEL bootstrap code that needs to be fixed by ensuring the MeterProvider's Resource is constructed with the same Resource.fromEnvironment() merge as the TracerProvider.

Label applied

bug — The reported behavior is not working as intended. The fix should be in the CLI binary: ensure the MeterProvider is initialized with Resource.default().merge(Resource.fromEnvironment()) (or language-equivalent) to match the TracerProvider.

Generated by Bug Handler for issue #1251 · ● 425.7K · ◷