One possible suggestion is the close the resClone4Hook's body. That probably will resolve this leak.

I looked into this a bit and made a reproduction for this: https://github.com/tildeio/otel-js-demos/tree/4888-fetch-memory-leak

@shuhaowu did a good job identifying the issue, and once you see the pattern, it's pretty obvious why this would happen. IMO it would be more clear to distill the problematic pattern down in a standalone demo without involving the instrumentation code, so that's what I did.

I did some digging and this was introduced in #2497. IMO, the feature was poorly motivated and is fundamentally incompatible with infinite/long streaming responses.

The context here is that applyCustomAttributesOnSpan is a hook that gets called only after the response is fully streamed. In #2497, the feature request was to preserve the ability to read/introspect the response body at that point, so in order to do that, the solution was to eagerly clone the response, hold on to it, and then pass that cloned response object to the hook when the response has finished streaming. This fundamentally forces the browser to buffer and hold on to the entire response body, and in the case of infinite/long-running streams, that is a fatal strategy.

Now, there is perhaps an argument here that infinite/long-running streams are also fundamentally incompatible with instrumentation anyway, as they hold up the span/trace which can cause other problems. However, because this is done automatically for all fetch requests, it can be hard to notice/trace down as @shuhaowu pointed out; in addition, based on the way the code is written today, the ignore* options doesn't really disable most of the instrumentation code, so it doesn't seem like it would have prevented this issue.

This current design isn't only problematic with infinite/long-running streams. For example, I imagine [citation needed] if the body is consumed via await response.json();, the browser could probably use a streaming JSON parser to parse the body into JS objects as it arrive, without buffering the raw response bytes. The current code would force the browser to always buffer and hold onto the response.

Overall, I tend to think that #2497 was a mistake. "response body can only be read once" is a fundamental design choice of the web platform and should be expected/respected. Eagerly cloning and holding on to the response object is essentially intentionally defeating the optimizations afforded by this design choice and there is a pretty high bar to clear there, and the original feature request just didn't provide a good reason for it. IMO, it probably should just be reverted. Alternatively, with the upcoming v2 timeline, breaking this in v2 may be safer, but at the expense of keeping around the unfixable memory issue in the v1 branch. (nvm, this is an experimental package)

A possible compromise is to add an extra hook that gets called with the original response object before the fetch promise resolves. It feels too easy to misuse however – if whoever uses the hook forgets to clone and consumed the response body, the caller of fetch will get an unusable response object which seems whacky. Since the original feature request didn't elaborate on the actual use case, it's hard to tell what problems it was trying to solve and what solutions would work best.

One possible suggestion is the close the resClone4Hook's body. That probably will resolve this leak.

I added an option to test this in my reproduction/demo app. As far as a I can tell, in Chrome at least, it doesn't do anything. But in any case, I think this is moot – the only reason that extra clone exists was to enable the hook to read the response body, and this suggestion would break that "feature". If we are walking back that "feature" anyway, we could just pass the original response object through to the hook at that point.