cc @dineshg13

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 79.7%. Comparing base (f5a1497) to head (c45623a).
Report is 1333 commits behind head on main.

@@          Coverage Diff          @@
##            main   #3707   +/-   ##
=====================================
  Coverage   79.7%   79.7%           
=====================================
  Files        171     171           
  Lines      12673   12673           
=====================================
  Hits       10103   10103           
  Misses      2357    2357           
  Partials     213     213           

Hoisting this as it was on a comment chain that got resolved:

On success, the server MUST respond with HTTP 200 OK.

If the request is only partially accepted (i.e. when the server accepts only parts of the data and rejects the rest), the server MUST respond with HTTP 200 OK.

Nothing other than a 200 OK response is according to spec.

The spec says All other HTTP responses that are not explicitly listed in this document should be treated according to HTTP specification. . Any 2xx should be treated as non-error . https://umbraco.com/knowledge-base/http-status-codes/#2xx

cc @Aneurysm9

In other SDKs / components:

• OTLP exporter in collector treats all codes in [200, 300) as success: https://github.com/open-telemetry/opentelemetry-collector/blob/892d07dffbb8dc639114bc0c340dfd4fc5293258/exporter/otlphttpexporter/otlp.go#L146-L149
• Java otlp http exporter treats all codes in [200, 300) as success: https://github.com/open-telemetry/opentelemetry-java/blob/3d73283a71a2a6e1d6dd5e725098f697b1edae03/exporters/common/src/main/java/io/opentelemetry/exporter/internal/okhttp/OkHttpExporter.java#L120

public boolean isSuccessful()
Returns true if the code is in [200..300), which means the request was successfully received, understood, and accepted.

• Python http exporter treats 200 and 202 as success: https://github.com/open-telemetry/opentelemetry-python/blob/209093bfbe3fae0fc29c693f55d6bb6a2d997aad/exporter/opentelemetry-exporter-otlp-proto-http/src/opentelemetry/exporter/otlp/proto/http/trace_exporter/__init__.py#L155

Haven't checked others but this seems something needs to be unified.

The 2xx (Successful) class of status code indicates that the client's request was successfully received, understood, and accepted.

• RFC 9110

The OTel spec for OTLP/HTTP says that servers must respond to fully or partially successful requests with 200 OK. That covers all successful HTTP response scenarios. Any server that responds with 201 Created or 202 Accepted are non-conformant. Encountering a non-conformant server is an error condition.

That other SDKs do something different doesn't mean that we need to follow their lead.

@Aneurysm9 @songy23 I have created an issue on Spec . open-telemetry/opentelemetry-specification#3203 . It looks like we need a clarification on the spec for this issue.

This PR was marked stale due to lack of activity. It will be closed in 14 days.

This is already addressed