fs: allow correct handling of burst in fs-events with AsyncIterator#58490
Merged
nodejs-github-bot merged 1 commit intonodejs:mainfrom Jun 10, 2025
Merged
fs: allow correct handling of burst in fs-events with AsyncIterator#58490nodejs-github-bot merged 1 commit intonodejs:mainfrom
nodejs-github-bot merged 1 commit intonodejs:mainfrom
Conversation
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This addresses a bug in
fs.watchwhen used as an AsyncIterator.The issue is that when consuming the AsyncIteractor returned by
fs.watchit yields a value. When using that value and in turn awaiting an asynchrounous action any events happening in the meantime will go missing. The reason is that between exiting the watch function by yielding and reentering it through the next round, thepromiseinside watch is already resolved. So any events generated will be duplicate resolutions of that promise and therefore ignored.More reaslistically than this minimal example is when the found files are actually read via
await fs.readFile. Then there will be a lag. If the file events happening are happening close together, then the second one will be missed.To fix this issue I added a queue to the watch function that new file events get pushed onto. The promise is no longer resolved with a value, but is simply the gate gating whether or not there are any events in the queue. The iterator awaits the promise and then yields the items from the queue so long as there are any. When the queue is empty and the watch is still running, then a new promise is created and awaited upon. This whould eliminate the problem entirely and one can now go asynchronous in the loop as long as one wants without missing events.
Verified that the added test fails with v24.0.0 and passes after the fix.
Based on feedback the queuing was made configurable with the
maxQueue(default2048) option determining the maximum size of the queue and theoverflowoption deciding to eitherignorethe issue orthrowan Error (default:'ignore'). To effectively get back the previous behavior one would have to pass{ maxQueue: 1, overflow: 'ignore' }.