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

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

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.

@gireeshpunathil

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 ?

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.

@gireeshpunathil

@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?

@gireeshpunathil

@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

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

@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?

@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

@MoLow

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)}

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.

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

Now that is surprising!

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

Refs: libuv/libuv#3866

It may be related to the deletion of the pFSEventStreamFlushSync call in libuv.

kqueue: use EV_CLEAR for fs event watchers

Navigation Menu

Repository navigation

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

Node.js Version

NPM Version

Operating System

Subsystem

Description

Minimal Reproduction

Output

Expected

Received

Before You Submit

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Node.js Version

NPM Version

Operating System

Subsystem

Description

Minimal Reproduction

Output

Expected

Received

Before You Submit

Activity

gireeshpunathil commented on May 21, 2024

Apokalypt commented on May 21, 2024

gireeshpunathil commented on May 21, 2024

Apokalypt commented on May 22, 2024

avivkeller commented on May 22, 2024

gireeshpunathil commented on May 23, 2024

jakecastelli commented on May 29, 2024

Apokalypt commented on May 29, 2024

avivkeller commented on May 29, 2024

saghul commented on May 29, 2024

Apokalypt commented on May 29, 2024

saghul commented on May 29, 2024

Shahindavoodicom commented on Jun 18, 2024

Tseian commented on Mar 26, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

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