fix(otlp-exporter-base): limit Node.js HTTP transport response body to 4 MB

[kartikgola]

Which problem is this PR solving?

Node.js HTTP transport in otlp-exporter-base accumulates response body chunks into a Buffer[] without any size limit. A misconfigured/misbehaving server could send an arbitrarily large response, causing the exporter to buffer it all in memory.

This implements the 4 MB response body limit also implemented by this opentelemetry-proto PR based on https://cwe.mitre.org/data/definitions/789.html.

Fixes #6539

Short description of the changes

In sendWithHttp(), the res.on('data') handler now tracks cumulative response size. If it exceeds 4MB (MAX_RESPONSE_BODY_SIZE), the stream is destroyed and the promise is resolved based on the HTTP status code:

• 2xx: returns success without response data (the export was already accepted)
• non-2xx: returns failure as a non-retryable error, since an oversized response indicates a misbehaving server
  The resolve() is called before res.destroy() so the subsequent ECONNRESET on req.on('error') becomes a no-op (since promise is already settled).

Note: The fetch transport (otlp-exporter-base/src/transport/fetch-transport.ts) used by browser exporter has not been changed because it never reads the response body so the vulnerability doesn't apply there. If required, we could have added something like response.body?.cancel().catch(() => {}); but it has no impact since it never reads the body.

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Three new unit tests added in http-exporter-transport.test.ts. Each spins up a real http.Server that writes oversized responses:

• 200 + body exactly at 4 MB limit → success with data
• 200 + body exceeding limit → success without data
• 503 + body exceeding limit → non-retryable failure
  All 146 existing node.js tests also pass.

Checklist:

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

[trentm]

Thanks for picking this up!

[trentm]

https://github.com/open-telemetry/opentelemetry-proto/pull/781/changes#diff-eebad86dc55e949d1d0630c4a2e92fed2a16b19e0ab623719ed429b5d3eee101R168-R169
states:

If the limit is exceeded, the client MUST treat the response as a not-retryable error.

Why have a resolve({ status: 'success' }); code path here?

[kartikgola]

Good point... I initially kept the 2xx path as success thinking the export was already accepted, but re-reading it, I think you're right. I will update to return failure for all oversized responses regardless of HTTP status.

Changes addressed

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.74%. Comparing base (9fed372) to head (adae9a4).
⚠️ Report is 8 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6552   +/-   ##
=======================================
  Coverage   95.73%   95.74%           
=======================================
  Files         369      371    +2     
  Lines       12497    12523   +26     
  Branches     2959     2963    +4     
=======================================
+ Hits        11964    11990   +26     
  Misses        533      533           

Files with missing lines	Coverage Δ
...xporter-base/src/transport/http-transport-utils.ts	95.89% <100.00%> (+0.57%)	⬆️

... and 7 files with indirect coverage changes

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

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: kartikgola / name: Kartik Gola (5f37e99, 77c4a5f, 80b6488, adae9a4, e231c9e)

[dyladan]

Should we hold this until the proto PR merges or no? Looks like not everyone did

[pichlermarc]

@dyladan I am fine with merging this. Since it's an internal change to the exporter, we can change the behavior again if the spec changes.

[trentm]

Thanks!

[otelbot]

Thank you for your contribution @kartikgola! 🎉 We would like to hear from you about your experience contributing to OpenTelemetry by taking a few minutes to fill out this survey.