fix: drain unobserved response body streams - #210
Closed
PekingSpades wants to merge 1 commit into
Closed
PekingSpades wants to merge 1 commit into
PekingSpades wants to merge 1 commit into
Conversation
Consume response tracking streams when no complete response listener needs buffering, preventing active responses from growing an unused queue outside the configured body size limit.
|
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A streaming response with no complete-response listener can fill the internal tracking PassThrough indefinitely. Its queue is outside the body reader's
maxBodySizelimit. Drain that stream when no complete response needs capturing, while preserving body-data events and observed response bodies.Fixes #209.
Complete reproduction: #209. Based on v4.6.3 (
10e33d5).Changes
Actual before/after comparison
The report's loopback reproduction sends 16 MiB with
recordTraffic: falseandmaxBodySize: 1024, consumes all bytes at the client, and holds the response open for measurement.Queue sizes depend on TCP chunking and can overlap; they are individual queue counters, not an exact summed RSS measurement.
Using the script from the report and a built checkout at
../mockttp:Validation
npm run build: passed.The full run failed in two existing live-network cases:
skips the server for non-matching HTTPS requests(TLS disconnect, also seen on the baseline) andforwards to the location even if the port & protocol is implicit(the public HTTP fixture returned a 502 AggregateError). A separate repeated probe reproduced the same HTTP fixture failure on both the baseline and this branch: upstream connect attempts reported ETIMEDOUT and ENETUNREACH. These failures remain visible in the reported totals.All validation used Node 24.19.0, with freshly installed upstream dependencies. Browser checks used Chrome Headless 151.0.7922.34. The full Node suite used a local pkimetal service and a 30-second Mocha timeout. Existing live-network outcomes vary between runs; the deterministic regression and loopback comparisons isolate these changes.