Provide some way to reliable know when FileSystemWatcher is listening for events

[vaclavHala]

In our tests it seems when we create a file watcher

const w = vscode.workspace.createFileSystemWatcher(...)

it actually does not start seeing file events for some time after creation.
I went through the docs and code briefly and it seems to really behave that way since the watcher is returned immediately, but in the background there is the machinery of dedicated file watcher process to which the request needs to be delivered by some RPC which is bound to create some delay even if everything else (other vscode internals, parcel, ...) starts the watch instantaneously.

While this is not a huge deal when a real user interacts with the extension (since people are inherently slow and are able to retry any action) it makes it very hard to test any code that depends on file watching in automated tests.

For example we need to do this

const unwrapper = new ProjectUnwrapper() // some code creating file watcher in constructor
await sleep(5000) // give the backing file watchers enought time to actually start watching
await vscode.workspace.fs.rename(j('foo.fizz'), j('bar.fizz'))
expect(unwrapper).reactedToFileEventSomehow()

Which works most of the time but breaks down when the CI is under load because the 5sec sleep is no longer enough.

We also tried watching the system log (by tailing the log file on disk and using this to unblock barriers in the test) with trace logging enabled as described here https://github.com/microsoft/vscode/wiki/File-Watcher-Issues but sometimes that did not work either + some ways of creating the watcher do not seem to produce any message into that log at all (e.g. when given just single string arg to the createFileSystemWatcher).

I think it'd be very useful to have some means provided by vscode API to know when one can reliably expect file events to be emitted e.g.

export interface FileSystemWatcher extends Disposable {
  onWatcherStateChanged: Event<FileWatcherState>;
}

export enum FileWatcherState {
  Preparing, // no events will arrive yet, watch is being set up
  Watching , // fully operational
  Degraded,  // e.g. when the dreaded "No more file descriptors" problem appears, 
             // some events might still appear but can't be relied on to be complete
}

If a full blown API is too heavy change, given this may not be used by most extensions in their production code, it might be enough to have a command provided by vscode that, given a watcher instance, returns boolean / enum as described above indicating if that instance is watching. We could then poll this command until it tells us the watcher is ready to go

const watcher = vscode.workspace.createFileSystemWatcher(...)
for(;await vscode.commands.executeCommand("fileWatcherState", watcher);){
    await sleep(500)
}
// now I can start testing code using watcher knowing it will not miss the initial events

this has obviously the downside that I'd have to keep polling the method to find out if the watcher becomes degraded later because e.g. many files were added into the workspace and I run out of file descriptors, but since it is mostly for testing where we have control over the environment it would be quite sufficient for our case

Originally asked in discussions microsoft/vscode-discussions#1242 where @theReynald confirmed this is currently not possible, thus this feature request.

[vscodenpa]

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[vs-code-engineering]

This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[vs-code-engineering]

🙁 In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.

Happy Coding!