OTLP/HTTP exporters should honor Retry-After

[pellared]

The OTLP/HTTP exporters currently retry transient HTTP failures using local exponential backoff, but they do not honor the Retry-After response header.

This is out of line with the OTLP/HTTP spec clarification in open-telemetry/opentelemetry-proto#806: Retry-After can be either an HTTP-date or a delay in seconds, and clients SHOULD honor the value when present.

I verified this against current main:

• exporter/opentelemetry-exporter-otlp-proto-http/src/opentelemetry/exporter/otlp/proto/http/_common/__init__.py has _is_retryable() returning true only for 408 and 5xx; 429 is not treated as retryable.
• The trace, metric, and log OTLP/HTTP exporters compute retry delays locally with exponential backoff and jitter.
• Those retry loops do not inspect response headers, so neither Retry-After: <delay-seconds> nor Retry-After: <HTTP-date> affects the next retry time.

Expected behavior

When an OTLP/HTTP response is retryable and includes Retry-After, the exporter should honor the header value before retrying.

The parser should support both forms defined by RFC 7231 section 7.1.3:

• delay-seconds, for example Retry-After: 5
• HTTP-date, for example Retry-After: Wed, 21 Oct 2015 07:28:00 GMT

It is also worth checking whether 429 Too Many Requests should be included in the HTTP retryable response handling for this exporter.

References

• Retry-After can be an HTTP-date opentelemetry-proto#806
• Retry-After can be an HTTP-date opentelemetry-proto#806 (comment)
• https://datatracker.ietf.org/doc/html/rfc7231#section-7.1.3

[liketosweep]

Hey , I'm considering taking a look at this. Please let me know if someone is already working on it.

[herin049]

This is being addressed in #5252