Skip to content

oss_10_otlp_partial_success#13

Open
ocelotl wants to merge 2 commits into
mainfrom
oss_10_otlp_partial_success
Open

oss_10_otlp_partial_success#13
ocelotl wants to merge 2 commits into
mainfrom
oss_10_otlp_partial_success

Conversation

@ocelotl

@ocelotl ocelotl commented Jul 22, 2026

Copy link
Copy Markdown
Owner

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

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.
@ocelotl

ocelotl commented Jul 22, 2026

Copy link
Copy Markdown
Owner Author

🔒 Internal (dash0) — not for upstream.

@ocelotl

ocelotl commented Jul 22, 2026

Copy link
Copy Markdown
Owner Author

📣 Public-facing draft — to be opened upstream in open-telemetry/opentelemetry-python. No internal references; copy verbatim.

Title: Handle OTLP partial_success responses (log rejected telemetry)

What

Deserialize 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 rejected_* count or a non-empty error_message). A shared _log_partial_success helper is added per transport.

Why

Previously 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

  • gRPC: bind the previously-discarded Export(...) return value and pass it to the helper.
  • HTTP: deserialize resp.content at each signal's export call site, before returning SUCCESS on resp.ok.
  • A partial success is still SUCCESS (the request was accepted); the change only logs. An unparseable body is swallowed so it cannot turn a successful export into a failure.

Testing

New 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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

oss_10_otlp_partial_success

1 participant