Strange behavior with fs.watch on file with JSON stringified -> first update isn't emitted if too fast after fs.watch

[Apokalypt]

Node.js Version

v18.17.1

NPM Version

9.6.7

Operating System

23.2.0 Darwin

Subsystem

fs

Description

I would like to watch changes on a file storing JSON stringified data but the watcher created with fs.watch is not emitted if the change happen to quickly after the call of fs.watch. The strange thing is that if the content is only a text (without JSON format) the watcher emit the event correctly...

Minimal Reproduction

const fs = require('fs');
const path = require('path');

const filePath = path.join(__dirname, 'test.json');
// Create the file if it doesn't exist
if (!fs.existsSync(filePath)) {
    fs.writeFileSync(filePath, "{ }");
}

fs.watch(filePath, (eventType, filename) => {
    console.log(`Event type is: ${eventType}`);
    if (filename) {
        console.log(`Filename provided: ${filename}`);
    } else {
        console.log('Filename not provided');
    }
});

fs.writeFileSync(filePath, "{ \"test\": \"test\", \"test2\": \"test2\" }"); // same with JSON.stringify(...)
// Listener above is called if we replace line above with:
// fs.writeFileSync(filePath, "very ok or not but I need a longer text to test something...");

Output

Expected

Event type is: change
Filename provided: test.json

Received

Nothing

Before You Submit

• I have looked for issues that already exist before submitting this
• My issue follows the guidelines in the README file, and follows the 'How to ask a good question' guide at https://stackoverflow.com/help/how-to-ask

[gireeshpunathil]

interesting!

able to reproduce with v20.12.2 too.

if I replace the writing section with this code:

if(process.argv[2] === 'json') {
	console.log('json')
	fs.writeFileSync(filePath, "{ \"test\": \"test\"}");
}
else {
	console.log('text')
	fs.writeFileSync(filePath, "hello!");
}

then the behaviour is arbitrary. sometimes the text change is called back, sometimes not. but the json callback is always omitted.

[Apokalypt]

Oh, I forgot to tell that I've also tested the behaviour on node version :

• 20.11.0
• 16.20.1

@gireeshpunathil Are you also on a MacOS computer or on another operating system ?

[gireeshpunathil]

yes - Mac . if I add an artificial delay using setTimeout before the write, things are fine; so looks like there is a race condition between the watch registration and the writing (though both are done by the same thread). not sure what is going on.

[Apokalypt]

@gireeshpunathil Do you think this could be considered as a bug and should be reported in the main repository containing the nodejs runtime source code?

[RedYetiDev]

@gireeshpunathil Do you think this could be considered as a bug and should be reported in the main repository containing the nodejs runtime source code?

Maybe, it seems like a bug IMO

[gireeshpunathil]

I deem it as a bug. the watch method does not talk about when it will be ready so the implicit assumption is as soon the call returns. it is also not specified / documented if it is an asynchronous API in which case it's last param call back could have been used as a completion indicator, but that is used for something else (the actual file change event handler). so a natural expectation is that the watch is in effect as soon as the call returns, but reported problem indicates that a small delay is required for the watch to function well - in darwin.

/cc @nodejs/platform-macos

[jakecastelli]

I dug a bit on this on and I think first of all this is a macOS related issue as it cannot reproduce on Linux. I think this its related to libuv as Moshe said in #53100

@Apokalypt do you consider to open an issue in libuv?

[Apokalypt]

I dug a bit on this on and I think first of all this is a macOS related issue as it cannot reproduce on Linux. I think this its related to libuv as Moshe said in #53100

@Apokalypt do you consider to open an issue in libuv?

I confess I hadn't thought of that. However, if the problem is on their side (which seems to be admitted by you 3), I'll take the time to make a ticket at libuv tomorrow

[RedYetiDev]

Added repro-exists label: #53111 (comment)

---

CC @nodejs/fs - FS Related Issue
CC @nodejs/libuv - Possibly a libuv issue
CC @MoLow - Involved with a possibly related issue: #53100

---

_{(Ignore my changes to confirmed-bug, I didn't realize it was added after switching to this repository)}

[saghul]

interesting!

able to reproduce with v20.12.2 too.

if I replace the writing section with this code:

if(process.argv[2] === 'json') {

	console.log('json')

	fs.writeFileSync(filePath, "{ \"test\": \"test\"}");

}

else {

	console.log('text')

	fs.writeFileSync(filePath, "hello!");

}

then the behaviour is arbitrary. sometimes the text change is called back, sometimes not. but the json callback is always omitted.

Have you tried using some text of equal length? I don't see how JSON affects anything since there is no processing of the data, but its length might affect things with regards to timing.

[Apokalypt]

interesting!
able to reproduce with v20.12.2 too.
if I replace the writing section with this code:

if(process.argv[2] === 'json') {

	console.log('json')

	fs.writeFileSync(filePath, "{ \"test\": \"test\"}");

}

else {

	console.log('text')

	fs.writeFileSync(filePath, "hello!");

}

then the behaviour is arbitrary. sometimes the text change is called back, sometimes not. but the json callback is always omitted.

Have you tried using some text of equal length? I don't see how JSON affects anything since there is no processing of the data, but its length might affect things with regards to timing.

(I'm not the one targeted by your answer, but I'm going to answer anyway since I did the tests before creating the problem)

When I've found out the bug, I tried with :

• text smaller (only 1 character)
• text of equal length
• huge text (~50 MB)

For every test, the result is the same -> the .watch callback is called right after the update while with JSON data (small or not) it's never received...

[saghul]

Now that is surprising!

[Shahindavoodicom]

tested this on linux and works ok

node version v21.7.1

uname -a
6.5.0-35-generic #35~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue May 7 09:00:52 UTC 2 x86_64 x86_64 x86_64 GNU/Linux