`fsPromise.writeFile` should catch stream's error and reject the promise.

[ackava]

Version

22.16.0

Platform

All

Subsystem

No response

What steps will reproduce the bug?

Following code fails with an application crash.

import fsp from "node:fs/promises";
import { createReadStream } from "node:fs";

try {
    const s1 = createReadStream("not-existent");
    await fsp.writeFile("new-file.txt", s1);
} catch (error) {
    console.log(`Sorry file copy failed`);
}

Instead it should just say that an error has occurred and reject the promise.

How often does it reproduce? Is there a required condition?

Everytime

What is the expected behavior? Why is that the expected behavior?

The application should not crash and an error should be thrown.

What do you see instead?

Application Crashes.

Reproduction Repository

ackava/node-write-file-promise-fail

This repo contains docker container source code to reproduce error in container. On windows machine, delay causes app to crash but in container, slight delay of 1 ms causes crash.

Workaround

So far following code works correctly with slight time differences, and does not crash the app, promise is rejected correctly.

        const writable = createWriteStream(outputFilePath);
        return pipeline(inputStream, writable, { end: true });

[Ethan-Arrowood]

Isn't that exactly what is happening in your script. When I run it locally, the fsp.writeFile() step throws and an error is caught. Logging the error shows the expected ENOENT.

import fsp from "node:fs/promises";
import { createReadStream } from "node:fs";

try {
    const s1 = createReadStream("not-existent");
    console.log('hello')
    await fsp.writeFile("new-file.txt", s1);
    console.log('goodbye')
} catch (error) {
    console.log(error);
    console.log(`Sorry file copy failed`);
}

❯ node test.mjs
hello
[Error: ENOENT: no such file or directory, open 'not-existent'] {
  errno: -2,
  code: 'ENOENT',
  syscall: 'open',
  path: 'not-existent'
}
Sorry file copy failed

[ackava]

You have changed the code, I think it is about timing, not putting console.log crashes the app. I tested this on three different windows machines and same is failing in docker container as well but for 22.16, I could not reproduce this in 22.14. Even slight delay of few milliseconds will cause this to work correctly, but immediately after createReadStream will fail.

Here is the repo you can test,
ackava/node-write-file-promise-fail

Try to adjust sleep to see the crash.

Isn't that exactly what is happening in your script. When I run it locally, the fsp.writeFile() step throws and an error is caught. Logging the error shows the expected ENOENT.

import fsp from "node:fs/promises";
import { createReadStream } from "node:fs";

try {
const s1 = createReadStream("not-existent");
console.log('hello')
await fsp.writeFile("new-file.txt", s1);
console.log('goodbye')
} catch (error) {
console.log(error);
console.log(Sorry file copy failed);
}

❯ node test.mjs
hello
[Error: ENOENT: no such file or directory, open 'not-existent'] {
  errno: -2,
  code: 'ENOENT',
  syscall: 'open',
  path: 'not-existent'
}
Sorry file copy failed

[Ethan-Arrowood]

Okay I think I see it now. So internally, I think the fsp.writeFile is invoking the readable via async iteration: https://github.com/nodejs/node/blob/main/lib/internal/fs/promises.js#L478-L481 and this leads into how Readables are creating in async iterables. And there is nothing monitoring the readable's error event so its uncaught hence the error you are getting. Or at least the syncronization between handling the error is incorrect. I think this is definitely a confirmed bug that is reproducible given different states of the event loop particularly with async tasks like the sleep or console.log

Would you like to submit a PR? If so, make sure to include tests. Thank you!

[ackava]

@Ethan-Arrowood It appears on different systems different kind of delay causes this, on alpine node image, sleep of 1 ms causes app to crash but it works without delay and on windows it crashes immediately after creation but it works with the delay. I don't know how can I reproduce a test case that works well in all systems.

I think I found out the root problem, following example doesn't crash, it means that the error is thrown between writeFile 's start reading and adding error handler. Since socket handle has lots of delay and retries, this example doesn't crash.

try {
    const s1 = net.connect(40, "444545454545");
    await fsp.writeFile(outFile, s1);
} catch (error) {
    console.log(`Sorry file copy failed`);
}

So basically it is failing on high speed SSDs where error is thrown immediately after read has started.