fix(exporters): use sendBeacon with empty headers

[YangJonghun]

Which problem is this PR solving?

Currently, sendBeacon is only used when configHeaders is falsy (undefined or null). However, when users pass an empty object {} as headers, the exporter falls back to fetch unnecessarily. Since sendBeacon has better reliability for telemetry (works even when page is closing), it should be used when there are no actual custom headers to send.

Short description of the changes

• Update inferExportDelegateToUse to use sendBeacon when configHeaders is either falsy or an empty object
• Add test case for empty headers object scenario

Type of change

• Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

• npm run test:browser - All tests pass
• Added test: uses the beacon delegate when headers is empty object

Checklist:

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

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.43%. Comparing base (a36e8e9) to head (6483fdb).
⚠️ Report is 130 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6216   +/-   ##
=======================================
  Coverage   95.43%   95.43%           
=======================================
  Files         317      317           
  Lines        9521     9521           
  Branches     2197     2197           
=======================================
  Hits         9086     9086           
  Misses        435      435           

🚀 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.

[raphael-theriault-swi]

Could you fix the formatting issue and add a changelog entry ?

[YangJonghun]

@raphael-theriault-swi
I’ve updated it! thanks for letting me know.
Also, I wanted to get your opinion.
As far as I know, sendBeacon has a limit on the body size.
Do we need any filtering in place for that?

[pichlermarc]

FYI, I know for a fact that people use that behavior to force the exporter to use fetch instead.
I don't think it's necessarily a bug.

[YangJonghun]

@pichlermarc
Thanks for the comment!

I understand that this change could be considered a kind of breaking change, but from a user’s perspective the implicit behavior you mentioned didn’t feel very intuitive to me.

Coming from a web API background, I was dynamically passing {} as headers and naturally expected the exporter to fall back to sendBeacon when the headers were empty. It was surprising to discover that this actually forced the use of fetch instead.

This PR is also related to the fetchLater transport addition I proposed in PR #6217. Right now it’s just a binary choice, so the {} behavior isn’t too hard to reason about, but once we introduce something like fetchLater as an additional transport, it may become even more confusing for users to predict which transport will be selected.

If we want to support forcing a specific transport, I think it might be clearer to introduce an explicit option such as 'auto' | 'fetchLater' | 'sendBeacon' | 'fetch' | 'xhr' and let users choose, rather than relying on this implicit {} behavior.

[github-actions]

This PR is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[YangJonghun]

As the sendBeacon transport was removed in PR #6391 , this PR is being closed.