Make OTLP exporter retry parameters configurable in JS so connect failures (e.g., ECONNREFUSED) can be retried for minutes

[vinayvennela]

Summary

When the OTLP endpoint is temporarily unavailable (e.g., Collector restarts) NodeJS apps often hit connect‑level failures such as ECONNREFUSED. Today, the JS OTLP exporters perform a small, hard‑coded exponential backoff retry and then drop the batch. There’s no way to extend the retry window (e.g., a couple of minutes) from application code, which leads to preventable data loss during short outages.

I’m proposing we expose the retry parameters (max attempts, backoff bounds, multiplier, jitter) as configuration on the JS OTLP exporters (HTTP/proto, HTTP/json, and ideally gRPC) so users can tune resiliency to their environments.

References:

• Retry constants live in otlp-exporter-base: experimental/packages/otlp-exporter-base/src/retrying-transport.ts (see constants around lines 20–24: MAX_ATTEMPTS = 5, INITIAL_BACKOFF = 1000, MAX_BACKOFF = 5000, etc.)
• Exporters are responsible for retry per the spec
• Current package docs show no way to customize retry for JS OTLP exporters.

---

Problem details

• In NodeJS, when the OTLP endpoint is briefly down/unreachable, the exporter emits connect errors (e.g., ECONNREFUSED).
• The exporter’s built‑in retry logic uses fixed constants (max 5 attempts, 1s initial backoff, 5s max backoff) and then drops the batch if it cannot connect. Users cannot raise these limits. [\

This behavior contradicts operational expectations for short Collector outages, especially when apps cannot guarantee startup ordering or run outside k8s.

---

Expected behavior

Provide a way to retry for minutes (operator‑tuned), not seconds, on transient network/connect errors—without requiring an external wrapper. For example:

const exporter = new OTLPTraceExporter({
  url: 'http://localhost:4318/v1/traces',
  retry: {
    maxAttempts: 30,
    initialBackoffMs: 1000,
    maxBackoffMs: 30000,  // 30s
    multiplier: 1.5,
    jitter: 0.2,
    // optionally: totalElapsedLimitMs or per-batch cap
  },
});

Environment variable support would also be helpful (aligned to the env var spec), e.g.:

OTEL_EXPORTER_OTLP_RETRY_MAX_ATTEMPTS=30
OTEL_EXPORTER_OTLP_RETRY_INITIAL_BACKOFF_MS=1000
OTEL_EXPORTER_OTLP_RETRY_MAX_BACKOFF_MS=30000
OTEL_EXPORTER_OTLP_RETRY_MULTIPLIER=1.5
OTEL_EXPORTER_OTLP_RETRY_JITTER=0.2

---

Actual behavior

Retry parameters are hard‑coded in retrying-transport.ts and not user‑configurable; batches are dropped after a short backoff window on ECONNREFUSED.

---

Proposed solution

1. Expose retry configuration on the OTLP exporters (constructor options + env vars), wired through otlp-exporter-base.
2. Maintain sane defaults equivalent to current constants, preserving backward compatibility.

---

Alternatives considered

• Using Collector as an agent/side car to ensure max availability

---

Risks / considerations

• Longer retries can increase memory pressure in the app; defaults should remain conservative.

[pichlermarc]

Right now, batches are dropped immediately on ECONNREFUSED, so the retry never happens at all. I suppose that's what you're running into.

#6147 should address this. Happy to re-evaluate this request or raise the max retries if this is still a problem once #6147 has been merged and released and the currently available timeout option is still not sufficient.

[jsokol805]

@pichlermarc we will need to expose this - current backoff code is hard-coded (initial backoff, number of retriess, jitter exponential), timeout only serves as a lower bound. It's impossible to set timeout higher than 8-12s (depending on random jitter)

[vinayvennela]

I agree with @jsokol805 . @pichlermarc Do you see any problem in making the max retries configurable?

[pichlermarc]

I don't agree with the idea that we need to make it configurable.

That being said, I do agree that there's an issue with the current backoff code. However, the cause of that is not a lack of configurability. IMO a user should not have to configure retry behavior in addition to the timeout - that seems like a bad experience to me. I think it should re-configure automatically in the background based on the timeout value provided by the end-user.

For instance, it the amount of max retries does not fit the timeout as it will never exceed the 8-12s, but the end-user sets a timeout of 30s, the amount of max retries should auto-fit to the configured timeout of 30s without the need for a user to interact with a max retries setting.

This keeps API surface minimal and is also more user-friendly. Also, the addition of new environment variables has essentially stopped as we transition towards a future with declarative (file-based) config, meaning that the only way to configure it would be directly in code, which I would like to avoid as the feature would be DOA for a large part of our user-base.

[vinayvennela]

Yes your argument does make sense. The only thing im not sure is whether timeout is applicable when we receive ECONNREFUSED error. I am not familiar with the codebase of this repo, but a quick look at #6417 shows it included this scenario, so hoping it would fix the issue.
If my understanding is correct we could close this feature request