oss_10_otlp_partial_success#13
Conversation
The OTLP gRPC and HTTP exporters never inspected the partial_success field of the export response, so spans, data points or log records rejected by the collector were silently dropped. Both transports now deserialize the export response for traces, metrics and logs and log a warning that includes the rejected count and any error message when a partial success is reported. The export result is unchanged: a partial success is still returned as SUCCESS since the request itself was accepted.
|
🔒 Internal (dash0) — not for upstream.
|
|
📣 Public-facing draft — to be opened upstream in Title: Handle OTLP WhatDeserialize the OTLP export response on both transports (gRPC and HTTP/protobuf) for all three signals (traces, metrics, logs), and log a warning when the collector reports a partial success (a non-zero WhyPreviously the exporters returned SUCCESS without ever inspecting the response body, so collector-rejected spans / data points / log records were dropped silently — data loss with no diagnostic. The OTLP exporter spec requires surfacing partial success. Details
TestingNew unit tests per transport/signal: (a) a partial-success response with a rejected count logs a warning containing the count; (b) a fully-successful response logs nothing. Existing suites pass (gRPC 69, HTTP 65). |
Closes #10
Fixes OTLP partial-success handling (Linear OSS-10, finding X1): both transports (gRPC + HTTP) and all three signals (traces, metrics, logs) now deserialize the export response and log a warning with the rejected count / error_message on partial success. A partial success is still a SUCCESS return; it is no longer silent data loss.
Linear issue: https://linear.app/dash0/issue/OSS-10/x1-otlp-partial-success-responses-ignored-all-signals-both-transports