feat(exporters): implement fetch-later-transport

[YangJonghun]

Which problem is this PR solving?

Adds support for fetchLater API as the preferred transport method for browser-based OTLP exporters. fetchLater provides reliability guarantees that the request will be sent even if the page is closed, making it ideal for telemetry data export.

Short description of the changes

• Add FetchLaterTransport class in src/transport/fetch-later-transport.ts
• Add createOtlpFetchLaterExportDelegate in src/otlp-browser-http-export-delegate.ts
• Update inferExportDelegateToUse to prioritize fetchLater over other transports when available
• Add unit tests for the new transport and delegate selection logic

Type of change

• New feature (non-breaking change which adds functionality)

How Has This Been Tested?

• npm run test:browser - All tests pass
• Added tests for FetchLaterTransport covering success, failure, QuotaExceededError, AbortSignal, and timeout scenarios
• Added tests for inferExportDelegateToUse to verify fetchLater is selected when available

Checklist:

• Followed the style guidelines of this project
• Unit tests have been added
• Documentation has been updated

[codecov]

Codecov Report

❌ Patch coverage is 90.90909% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 95.47%. Comparing base (f15aa7e) to head (7ee5cac).
⚠️ Report is 127 commits behind head on main.

Files with missing lines	Patch %	Lines
...rter-base/src/otlp-browser-http-export-delegate.ts	50.00%	2 Missing ⚠️
...porter-base/src/transport/fetch-later-transport.ts	95.83%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6217      +/-   ##
==========================================
- Coverage   95.48%   95.47%   -0.02%     
==========================================
  Files         363      364       +1     
  Lines       11564    11596      +32     
  Branches     2669     2677       +8     
==========================================
+ Hits        11042    11071      +29     
- Misses        522      525       +3     

Files with missing lines	Coverage Δ
...rc/configuration/create-legacy-browser-delegate.ts	75.00% <100.00%> (+8.33%)	⬆️
...porter-base/src/transport/fetch-later-transport.ts	95.83% <95.83%> (ø)
...rter-base/src/otlp-browser-http-export-delegate.ts	57.14% <50.00%> (-2.86%)	⬇️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[pichlermarc]

cc @open-telemetry/browser-maintainers - is that something you would like to include at this time?

[trentm]

@overbalance Would you be willing to summarize your thoughts on this from the discussion at the last Browser SIG?

[overbalance]

@pichlermarc @trentm I was crafting the response as your comment popped up :)

The main issues with fetchLater are that it provides no access to the response meaning it cannot be retried, and browser support is lacking. Fetch with keepalive requests are attempted and retried when they are called, presumably providing more data, more quickly. I can't speak for the entire group but I think losing retry is a dealbreaker. There could be a smart way to use it in the future because it has the ability to abort pending requests before page exit. That may be a feature some users are interested in.

[pichlermarc]

Closing this as won't do for now, we may change our position once fetchLater has been adopted more broadly.

[YangJonghun]

@trentm @overbalance @pichlermarc
First of all, thank you for sharing the outcome of the internal discussion in the comments.

If there are any records or notes from that discussion, I would appreciate the opportunity to review them. I am also curious whether this PR was closed primarily due to the difficulty of implementing retries.

While I understand and agree that the lack of retry support can be inconvenient, this approach can still be used in conjunction with fetch depending on visibility. In the browser environment, key performance metrics such as LCP, CLS, and INP are determined based on the final state at the time of page unload. From this perspective, reducing the risk of data loss during page exit is more critical than supporting retries.

Given that fetch can still be chosen as a fallback when retries are required, I believe it is more beneficial not to eliminate this option entirely. Instead, allowing OpenTelemetry users to choose the most appropriate approach for their use case would better serve the community. If users are forced to implement custom solutions whenever they need this behavior, it could reduce the value of offering this as part of the standard.

[overbalance]

@YangJonghun can you explain what you mean by "difficulty of implementing retries"? Regarding page unload, can you explain how fetchLater reduces risk over fetch with keepalive? I agree options are good.