{"version":"2.1.281","anchor":"otlp-trace-exporters-get-an-export-outcome-hook-skipped-whe","canonical_anchor":"otlp-trace-exporters-get-an-export-outcome-hook-skipped-whe","heading":"OTLP trace exporters get an export-outcome hook, skipped when the traces endpoint is the startup gateway","tier":"internal","area":"Telemetry","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.281\/e\/otlp-trace-exporters-get-an-export-outcome-hook-skipped-whe","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.281","markdown":"### OTLP trace exporters get an export-outcome hook, skipped when the traces endpoint is the startup gateway\n\nOpenTelemetry trace exports now report each export's result through a callback, except when traces go to the startup gateway\n\n**Unclear.** The finding does not say what the per-export callback does with each result.\n\n**What**\n\nClaude Code can send traces to a telemetry service you choose, using OpenTelemetry (OTLP). A trace is a timed record of the steps in a piece of work. The service address comes from the environment variable `OTEL_EXPORTER_OTLP_TRACES_ENDPOINT`.\n\nA new check looks at that address. If it matches an address known when Claude Code started and its path is for traces, it counts as the startup gateway. In every other case, Claude Code now records which protocol is used and whether the export goes through a proxy (`{protocol, viaProxy}`), and calls a result callback after each export.\n\nThe \"[3P telemetry] First ... export\" debug message is unchanged.\n\n**Why**\n\nIf you send traces to your own telemetry service, Claude Code now tracks how each export went. When traces go to the startup gateway, this extra tracking is skipped.\n\n- Area: Telemetry\n- Names: `OTEL_EXPORTER_OTLP_TRACES_ENDPOINT`\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 1\/5"}