HTTP Instrumentation responseHook breaks streams when used with axios

[dinumihnea]

What happened?

The issue happens when using @opentelemetry/instrumentation-http with Axios streams (responseType: stream) and the server sends the response as a single chunk. In this case, the response.on("data") event is not triggered, and the single-chunk response is lost, disrupting the stream. This behavior does not occur when using the native http module or fetch.

Steps to Reproduce

This repo will help to reproduce the issue https://github.com/dinumihnea/opentelemetry-axios-stream-issue

The conditions to replicate the issue are very specific:

• @opentelemetry/instrumentation-http responseHook intercept the response.on("data") event
• axios responseType is stream
• the server provides the response in a single chunk

When these 3 conditions are met the single response chunk is lost.

I wasn't able to reproduce the issue when using native http module or fetch.

Expected Result

Streams to work even if they're intercepted by the responseHook

Actual Result

Streams are disrupted when instrumentation-http responseHook is configured - the response.on("data") listener is not invoked.

Additional Details

1. In some cases, this issue also occurs when large files are streamed. I observed multiple instances where the interceptor caused files to be streamed with missing chunks. However, I was unable to consistently reproduce this behavior and chose to disable the interceptor for large file streams as a temporary solution.
2. As a workaround, for single-chunk responses issue I started using res.prependListener("data", ...) instead of res.on("data", ...) in the responseHook, however this doesn't seem right. This workaround suggests that the issue may be related to how the @opentelemetry/instrumentation-http package manipulates the order of events.

I hope this additional info is helpful.

OpenTelemetry Setup Code

// see https://github.com/dinumihnea/opentelemetry-axios-stream-issue/blob/main/instrumentation.js
// and https://github.com/dinumihnea/opentelemetry-axios-stream-issue/blob/main/app.js

package.json

{
  "name": "opentelemetry-axios-stream-issue",
  "version": "0.0.0",
  "description": "",
  "license": "ISC",
  "author": "",
  "type": "commonjs",
  "main": "app.js",
  "scripts": {
    "start": "node app.js"
  },
  "dependencies": {
    "@opentelemetry/api": "^1.9.0",
    "@opentelemetry/auto-instrumentations-node": "^0.56.0",
    "@opentelemetry/exporter-trace-otlp-proto": "^0.57.1",
    "@opentelemetry/instrumentation-http": "^0.57.1",
    "@opentelemetry/resources": "^1.30.1",
    "@opentelemetry/sdk-metrics": "^1.30.1",
    "@opentelemetry/sdk-node": "^0.57.1",
    "@opentelemetry/sdk-trace-node": "^1.30.1",
    "@opentelemetry/semantic-conventions": "^1.29.0",
    "axios": "^1.7.9"
  }
}

Relevant log output

Operating System and Version

macOS 15.3 and Debian 12

Runtime and Version

Node v22.13.0 and v20.18.1

[dyladan]

I'm not sure if this is a bug or not. Adding event handlers to the response object in the hook can have side-effects that are difficult to detect and handle in the SDK. Without looking into this further, I'm not sure if I can say whether this is a bug on our end or just an unsupported usecase.

[dinumihnea]

I'm not sure if this is a bug or not. Adding event handlers to the response object in the hook can have side-effects that are difficult to detect and handle in the SDK. Without looking into this further, I'm not sure if I can say whether this is a bug on our end or just an unsupported usecase.

thanks for the reply @dyladan ,

In our case, we learned this "the hard way." Initially, we encountered files with missing chunks, and later discovered that when we tried to promisify a stream, the promise would never resolve (these two scenarios seem to have the same cause as described in the bug-report).
It took us quite some time to debug and eventually figure out that this issue only occurs when OpenTelemetry is enabled.

Whether this is considered a bug or not is, of course, up to you to decide. However, if this behavior isn’t addressed, it would be incredibly helpful to at least include a warning in the documentation. Alternatively, having an option to disable HTTP interceptors for streams would be a great addition.