[correctness] Save failures for streamed child resources are silently swallowed

In v6, waitForLoad saved every resource via series(), so a disk-full/EACCES error while writing any image rejected scrape() when ignoreErrors: false (the default). Now non-html/css resources are persisted inside the request queue task: the error rejects requestPromise, but for child resources that promise is only awaited via Promise.allSettled in downloadChildrenResources, so the rejection is discarded. scrape() resolves successfully while the saved output is silently missing files, and the error action never fires.

Note this call also bypasses the saveResource wrapper (line 155), so there isn't even a failed to save resource warn for child resources.

[correctness] Live response stream leaks when generateFilename throws

If a generateFilename action throws (or returns null, making this destructuring throw a TypeError), the live got stream obtained at line 176 is never consumed or destroyed — cleanup only exists inside persistResource's finally and via readAll consumption, both of which are only reached later. The paused HTTP response keeps its TCP socket open indefinitely.

Reproduced live: with ignoreErrors: true and a filename plugin that throws for one URL, the process is left with open socket handles after scrape() resolves and never exits.

Same applies to any throw between request.get resolving and stream consumption (e.g. lines 202–217). A try/catch around that region that destroys responseData.stream before rethrowing would cover all of these paths.

[correctness] Multiple saveResource actions re-buffer the whole body as a string, breaking the streaming guarantee

With more than one saveResource action registered (e.g. filesystem + S3 upload), this buffers the full body via Buffer.concat(chunks).toString('binary'):

• For files ≥ ~512 MiB, toString throws Cannot create a string longer than 0x1fffffe8 characters, so the resource fails to save.
• Below that limit, the v7 headline promise that memory no longer grows with resource size is silently broken whenever a second saveResource action exists.
• The latin1 string round-trip also allocates the content twice (Buffer → string → Buffer per action) instead of buffering once as a Buffer.

Buffering as a Buffer (and exposing it via the content stream per action) would at least fix the throw and the double allocation; documenting the multi-action buffering behavior would cover the rest.

[correctness] getBody memoization is not concurrency-safe

The bufferedBody === null check and the assignment straddle an await. If an afterResponse action calls getBody() twice without awaiting the first call (e.g. Promise.all([hashBody(response), inspectBody(response)]) where each helper calls getBody), both invocations start reading the same one-shot stream and split the chunks between them — each gets a corrupted/partial body, and whichever finished last is what ends up written to disk.

Memoizing the promise instead of the resolved value fixes it:

let bufferedBodyPromise = null;
const getBody = () => {
	bufferedBodyPromise ??= readStreamToBuffer(originalStream);
	return bufferedBodyPromise;
};

[correctness / breaking change] afterResponse returning {body: null} now throws instead of skipping the resource

In v6, getData({body: null}) returned null and transformResult treated it as "skip this resource gracefully". Now {body: null} (or {body: undefined}) falls through to this branch and throws Wrong afterResponse result. Expected null or object..., but received object — with the default ignoreErrors: false, a v6 plugin doing this on a root URL aborts the entire scrape.

Either restore the skip semantics (if (result.body === null || result.body === undefined) { originalStream.destroy(); return null; } before the type check) or document the narrowing in MIGRATION.md.

[correctness / breaking change] saveResource actions are no longer invoked serially

v6 saved all resources one at a time via series() in waitForLoad, so saveResource actions never overlapped. Now streamed resources are persisted inside their request queue tasks, concurrently and unbounded by default (requestConcurrency: Infinity). A plugin writing to a shared, non-concurrency-safe sink (appending to a zip/tar archive, a single log file, a serial DB connection) that worked in v6 will now produce corrupted output or "connection busy" errors.

Worth documenting in MIGRATION.md ("saveResource actions may run concurrently; use requestConcurrency: 1 or make your action concurrency-safe").

[cleanup] readAll re-implements stream/consumers buffer(), less robustly

lib/request.js already imports buffer from stream/consumers (as readStreamToBuffer); this hand-rolled equivalent plus its 34-line test file could be replaced with (await buffer(stream)).toString(encoding).

The manual Buffer.concat(chunks) is also less robust: it throws TypeError: list argument must be an Array of Buffers if a plugin supplies a string-mode stream (e.g. resource.setContentStream(Readable.from('text'))) and the multi-saveResource buffering path in scraper.js runs, whereas stream/consumers buffer() handles string chunks.

[cleanup] originalStream.destroy() is repeated across five separate branches

Every early exit in this function (catch at line 84, null result at 89, type check at 94, non-buffer body at 108, body-replaced at 112) must remember its own destroy() call — any future early-return or throw added here (e.g. a new validation on result.encoding) silently leaks the got socket unless the author adds a sixth call.

A simpler shape: run the body in one try/catch that destroys and rethrows, and destroy in a single place at the end whenever the returned stream !== originalStream and the body was never read.

[cleanup] Save failures of streamed resources are logged as "failed to request resource"

For non-html/css resources, persistResource is awaited inside the queue task (line 228), bypassing the saveResource wrapper's failed to save resource warn at line 159 — so a disk-full or permission error thrown by a saveResource action surfaces here as failed to request resource, pointing diagnostics at the network instead of storage.

[cleanup] outputFile is now dead code

Its only caller (save-resource-to-fs-plugin.js) was switched to outputFileStream, and lib/utils/fs.js is not part of the package exports map — no caller remains anywhere in lib/, test/, or index.mjs. Keeping it means readers must reason about two write paths (buffered vs streamed) when only one is live; it can be deleted along with its export.