fix(transport): track cumulative inflight keepalive bytes and count

[overbalance]

What problem is this solving?

The fetch spec's 64KiB keepalive limit is cumulative across all inflight keepalive requests per fetch group, not per-request. Two concurrent 30KiB requests exceed the real 64KiB limit while both passing a per-request check. Chrome also enforces a 9-request concurrent keepalive limit per renderer process. Exceeding either limit fails with an opaque TypeError indistinguishable from a network error, silently losing data.

Short description of changes

• Track cumulative inflight keepalive bytes and request count at module level
• Only set keepalive: true when the request fits within a conservative 48KiB cumulative budget and the concurrent count is under 9
• Reserve keepalive budget synchronously before compression to prevent race conditions between concurrent send() calls; adjust to actual compressed size after compression completes
• Decrement counters in finally block so budget is freed on both success and failure
• Log via diag.warn when keepalive is downgraded, including which limit was hit
• Log via diag.warn on fetch failure and diag.debug on HTTP error responses
• Add tests for cumulative byte budget, concurrent count limit, counter decrement on success/failure, and diagnostic logging

Note on compression error handling

Compression now runs inside the try block, so compression failures return { status: 'failure' } instead of propagating as uncaught errors. This is intentional: it makes compression failures consistent with other transport errors and prevents unhandled promise rejections.

Testing

• npm run test
• npm run validate

[github-actions]

Chrome DevTools Protocol Tracing (Script: 118.50ms, Heap: 12.67MB)

	Number of Requests	Size of Requests	Script Duration	Task Duration	Heap Used Size
Requests	+3 requests	+30.04 KB
Page Loaded			+16.65 ms	+17.66 ms	+1.02 MB
Generate 100 fetch requests			+23.83 ms	+97.35 ms	+1.78 MB
Generate 100 XHR requests			+46.10 ms	+130.77 ms	+2.06 MB
Click 100 buttons and generate 100 logs			+21.99 ms	+26.89 ms	+3.23 MB
Throw a 100 exceptions			+2.47 ms	+24.14 ms	+2.25 MB
End Session			+7.47 ms	+8.85 ms	+2.34 MB
Total	+3 requests	+30.04 KB	+118.50 ms	+305.66 ms	+12.67 MB

Lighthouse (Script Eval: 55.26ms)

	Difference	Description
Total Blocking Time	0 ms	Difference in Total Blocking Time: Sum of all time periods between FCP and Time to Interactive, when task length exceeded 50ms, expressed in milliseconds. Learn more about the Total Blocking Time metric.
Main Thread Time	+75.55 ms	Difference in Main Thread Time: Consider reducing the time spent parsing, compiling and executing JS. You may find delivering smaller JS payloads helps with this. Learn how to minimize main-thread work
Script Evaluation Time	+55.26 ms	Difference in Script Evaluation Time: Consider reducing the time spent parsing, compiling, and executing JS. You may find delivering smaller JS payloads helps with this. Learn how to reduce Javascript execution time.

Platform Tests (vite-7 es2015 gzip: 66.58KB)

vite-6 Platform Tests

	Total Uncompressed Size	Total Gzip Size
vite-6 - es2015	+187.11 KB	+66.64 KB

vite-7 Platform Tests

	Total Uncompressed Size	Total Gzip Size
vite-7 - es2015	+187.11 KB	+66.58 KB

webpack-5 Platform Tests

	Total Uncompressed Size	Total Gzip Size
webpack-5 - es2015	+136.17 KB	+49.72 KB

[joaquin-diaz]

At this point we're at risk of not sending the request if the tab closes before it's out right? Should we store something in localStorage and send some flag on the next session so we can start having some metrics on how often this happens?

[overbalance]

Great idea. I'll have to test it. I think you're out of time if we try on page exit if you are queuing a request and also then attempting a synchronous write to localStorage.