Task · CFO-0070

Verify OTLP HTTP partial-success rejection reporting

Description

Loop15 source review of the pinned OpenTelemetry Go HTTP metrics exporter v1.46.0 found a potential partial-success reporting gap: errors.Join evaluates uploadErr before a request callback assigns rejected-datapoint errors to that variable. This was inspected in cached source, not reproduced against a fake endpoint, and no live rejection is asserted. Application export-success markers therefore cannot currently establish complete acceptance for a missing failure-counter proof. The existing atomic-window delivery task covers transport failure and flush gating, not this SDK partial-acceptance boundary. No dependency change or deployment is authorized by this capture.

Acceptance Criteria

Definition of Done

Implementation Plan

Loop 16 S70 drives the pinned real exporter through cf2otel using full-acceptance and partial-success HTTP responses, records the observed reporting contract, and documents the consequence without changing dependencies.

Implementation Notes

Loop16 S70-I1 implementation count 1, review-repair count 0, infrastructure retries 0. REV-S70 PASS 75e552f193d9c6b52911b3c27a35acb7916054a2; exact patch cherry-picked as 2d04726 and pushed in 4f14d92189703ab26752f663d5c6b3502e0e2da4. Valid protobuf metric partial rejection reaches caller and observer error and failure outcome; no defect reproduced. Deliberate contrary hypothesis failed by assertion, control and candidate passed; this is a spike, not repaired production code. CodeRabbit zero findings and integrated just check passed. No dependency change or backend storage claim. Landing CI pending watcher.

View the source file on GitHub