fs: handle early writeFile stream errors

[cookesan]

The fs.promises.writeFile() stream path could miss a readable
error emitted before the destination file opened. The returned promise
could reject while the source stream error also surfaced as an uncaught
exception.

This attaches a temporary error listener for readable stream inputs
before opening the destination, checks recorded stream errors before and
during async iteration, and removes the listener when the write finishes
or when opening the destination fails. FileHandle.writeFile() uses the
same helper.

Tests cover early readable errors for path and FileHandle writes, plus
listener cleanup when opening the destination fails.

Tests:

ninja -C out/Release -j4
python3 tools/test.py --shell out/Release/node parallel/test-fs-promises-writefile parallel/test-fs-promises-file-handle-writeFile
make lint-js

Fixes: #58742

[codecov]

Codecov Report

❌ Patch coverage is 98.63014% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 90.16%. Comparing base (c8e2a82) to head (e2a951d).
⚠️ Report is 3 commits behind head on main.

Files with missing lines	Patch %	Lines
lib/internal/fs/promises.js	98.63%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main   #63472   +/-   ##
=======================================
  Coverage   90.16%   90.16%           
=======================================
  Files         746      746           
  Lines      242760   242820   +60     
  Branches    45765    45789   +24     
=======================================
+ Hits       218875   218946   +71     
+ Misses      15375    15352   -23     
- Partials     8510     8522   +12     

Files with missing lines	Coverage Δ
lib/internal/fs/promises.js	93.17% <98.63%> (+0.17%)	⬆️

... and 31 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.

[cookesan]

Pushed a follow-up for the failing writeFile stream cases.

The already-errored stream path now keeps the temporary error listener through the pending next-tick error emission, then removes it. The tests also wait that tick before asserting listener cleanup. The FileHandle early-error test now accounts for the stream async iterator's own retained listener on that path.

Local validation:

• make -j8
• python3 tools/test.py --mode=release parallel/test-fs-promises-file-handle-writeFile parallel/test-fs-promises-writefile
• make lint-js LINT_JS_TARGETS="lib/internal/fs/promises.js test/parallel/test-fs-promises-file-handle-writeFile.js test/parallel/test-fs-promises-writefile.js"
• git diff --check

[cookesan]

Current blocker looks unrelated to this patch: the only failed check is x86_64-darwin: with shared libraries, and the log shows a timeout in parallel/test-tick-processor-arguments.js. This PR only touches lib/internal/fs/promises.js and the two writeFile tests.

I tried to rerun the failed jobs, but GitHub requires repository admin permissions. Could someone with access rerun the failed shared-libraries job?

[cookesan]

Following up now that the PR is approved: the only red check is still x86_64-darwin: with shared libraries, from an unrelated timeout in parallel/test-tick-processor-arguments.js.

I do not have permission to rerun that job. Could someone with access rerun the failed shared-libraries check when convenient?

[cookesan]

Following up once more since the PR is approved and mergeable. The only red job remains x86_64-darwin: with shared libraries; its log times out in parallel/test-tick-processor-arguments.js, which is outside this patch. The patch-specific tests and all other visible checks are green.

I still lack permission to rerun that job. Could a maintainer rerun that shared-libraries job when convenient?

[trivikr]

I don't see an option to re-run the failed CI.

@cookesan Can you please rebase from main and force push with lease?

[cookesan]

Done — rebased onto main and force-pushed with lease. Locally, the release build, the two focused filesystem tests, and targeted JS lint pass.

[trivikr]

The abort check runs before the temporary stream error listener is attached. If data is already errored and the signal is already aborted, writeFile() rejects with AbortError, but the pending stream error is still emitted as an uncaughtException. Attach the handler first and clean it up when the abort check throws:

Suggested change

	checkAborted(options.signal);
	const streamErrorHandler = makeWriteFileStreamErrorHandler(data);
	const streamErrorHandler = makeWriteFileStreamErrorHandler(data);
	try {
	checkAborted(options.signal);
	} catch (err) {
	streamErrorHandler?.cleanup();
	throw err;
	}

A regression test would look like this:

controller.abort();
stream.destroy(sourceError);
process.once('uncaughtException', mustNotCall());
await assert.rejects(writeFile(target, stream, { signal }), { code: 'ABORT_ERR' });
await nextTick();
assert.strictEqual(stream.listenerCount('error'), 0);

The same case should be covered for both path-based writeFile() and FileHandle.writeFile().