feat(otlp-exporter-base): allow configuring fetch keepalive for browser OTLP exports

[alesiahancharuk]

Problem

FetchTransport in @opentelemetry/otlp-exporter-base enables keepalive: true for payloads under the browser keepalive limits (60KB / 9 concurrent). That is great for unload-safe delivery, but some browsers — notably Smart TV Chromium builds (LG webOS, Samsung Tizen) — reject fetch when both:

1. keepalive is set, and
2. the request requires a CORS preflight

Typical OTLP/HTTP JSON exports always preflight because they send Content-Type: application/json and often a collector Authorization header. On those platforms every export fails with:

Preflight request for request with keepalive specified is currently not supported

There is currently no public configuration to disable keepalive for browser OTLP exporters.

Proposal

Expose an option on the browser OTLP HTTP exporter / fetch transport, e.g.:

keepalive?: boolean // default: current auto behavior

When keepalive: false, skip the size/count keepalive budgeting and always call fetch without keepalive.

Workaround

We currently force keepalive: false via patch-package on @opentelemetry/otlp-exporter-base until this is available upstream.

References

• Fetch keepalive + CORS preflight limitation (TV Chromium)
• Related: fix(otlp-exporter-base): remove sendBeacon in favor of fetch with keepalive #6391 (sendBeacon → fetch+keepalive)
• WHATWG keepalive limits: Specify restriction for requests with keepalive set whatwg/fetch#679

[iamhaseebn]

Hi, I'd like to work on this. I traced the browser exporter path from OTLPExporterConfigBase through convertLegacyBrowserHttpOptions() to FetchTransport. My proposed scope is:

• add a browser-facing keepalive?: boolean option while preserving the current behavior unless it is explicitly set to false;
• thread it into the fetch transport without changing the existing Node.js agent keepAlive option;
• bypass the keepalive size/count accounting when the option is disabled;
• add browser and configuration tests for the default and opt-out paths;
• update the exporter documentation and experimental changelog.

Because this introduces public configuration, could a maintainer confirm the option name and whether it should live on OTLPExporterConfigBase before I open the pull request?