MockFileSystem.File.Move raises FileSystemWatcher event with delay #2

[teneko]

Continuation of #930 (I am not the author)

I do not get a reliable way to get the hand on the aggregated change events similiar to author of the above issue.

I also think to block the thread as the method doc indicates is a bit harsh.

I use

using var watcher = fileSystem.FileSystemWatcher.New("/");
watcher.IncludeSubdirectories = true;
watcher.EnableRaisingEvents = true;

const string fileName = "test.txt"

List<WatcherChangeTypes?> changes = [];

using var changeWatcher = fileSystem.Watcher.OnTriggered(x => {
    if (x.Path.EndsWith(fileName)) {
        changes.Add(x.ChangeType);
    }
});

..operate on file system..

const int timeoutInSeconds = 5 * 1000;
changeWatcher.Wait(timeout: timeoutInSeconds);

// Assumptions
changes.FirstOrDefault().ShouldBe(WatcherChangeTypes.Created);
changes.LastOrDefault().ShouldBe(WatcherChangeTypes.Deleted);

Whatever timeout I choose, the wait timeout is exhausted no matter what leading to an timeout exception. Only if I set a breakpoint between "..operate on file system.." and "changeWatcher.Wait" it works as inteded. Pretty sure the notifications are not buffered / not replayed!?

Can we please enable the following workflow:

using var watcher = fileSystem.FileSystemWatcher.New("/");
watcher.IncludeSubdirectories = true;
watcher.EnableRaisingEvents = true;

const string fileName = "test.txt"

List<WatcherChangeTypes?> changes = [];

using var changeWatcher = fileSystem.Watcher.OnTriggered(x => {
    if (x.Path.EndsWith(fileName)) {
        changes.Add(x.ChangeType);
    }
});

const int timeoutInSeconds = 5 * 1000;
// count = 3 (Created -> Changed -> Deleted)
var changeWatchedTask = changeWatcher.WaitAsync(timeout: timeoutInSeconds, count: 3);

..operate on file system..

// Assumptions
await changeWatchedTask; // if timeout exhausts throw as usual
changes.FirstOrDefault().ShouldBe(WatcherChangeTypes.Created);
changes.LastOrDefault().ShouldBe(WatcherChangeTypes.Deleted);

Here the corresponding extension method making above drawn workflow work:

file static class AwaitableChangeDescriptionCallbackExtensions
{
    extension<TValue>(IAwaitableCallback<TValue> awaitableCallback)
    {
        public Task WaitAsync(
            Func<TValue, bool>? filter = null,
            int timeout = 30000,
            int count = 1,
            Action? executeWhenWaiting = null,
            CancellationToken cancellationToken = default)
        {
            return Task.Factory.StartNew(
                static state => {
                    var (awaitableCallback, filter, timeout, count, executeWhenWaiting, cancellationToken) =
                        (ValueTuple<IAwaitableCallback<TValue>, Func<TValue, bool>?, int, int, Action?, CancellationToken>)state!;
                    
                    cancellationToken.ThrowIfCancellationRequested();

                    awaitableCallback.Wait(
                        filter,
                        timeout: timeout,
                        count: count,
                        executeWhenWaiting is not null ? ExecuteWhenWaiting : null);

                    return;

                    void ExecuteWhenWaiting()
                    {
                        cancellationToken.ThrowIfCancellationRequested();
                        executeWhenWaiting();
                    }
                },
                (awaitableCallback, filter, timeout, count, executeWhenWaiting, cancellationToken),
                cancellationToken,
                TaskCreationOptions.DenyChildAttach,
                TaskScheduler.Default);
        }
    }
}

[vbreuss]

With the current API you have to execute your operations on the file system during the callback:

using var changeWatcher = fileSystem.Watcher.OnTriggered(x => {
    if (x.Path.EndsWith(fileName)) {
        changes.Add(x.ChangeType);
    },
    executeWhenWaiting: () => 
    {
        // ..operate on file system..
    }
});

I agree that this is probably not the most intuitive syntax and will have to think about possible alternatives...

[teneko]

It would make much more sense to define assumptions like in the workaround I proposed. I mean building promises that fulfill once file system conditions have been met. I mean you currently can do that now, it is currently just glue code/boiletplate code you need to write manually.

I think there is not much you can do. You have a file system that fires events.. that gives us the way to observe the file system changes. that's great. before we change the file system, we make assumptions/define expectations. I also could use TaskCompletionSource in triggerCallback of ChangeHandler.OnTriggered and SetResult(..) once the expectation has met, or SetCanceled after x seconds (e.g. via cancellationToken.CancelAfter) or use ((TaskCompletionSource)tcs).Task.WithCancellation. So many ways.

[vbreuss]

My current thought is, that if we change this, I would like to add some more functionality (like getting the actual values of the callbacks). Something along the line to add the following method to the IAwaitableCallback signature:

/// <summary>
///     Waits asynchronously until the callback is executed.
/// </summary>
/// <param name="filter">
///     (optional) A filter for the callback to count.<br />
///     Defaults to <see langword="null" /> which will consider all callbacks.
/// </param>
/// <param name="count">
///     (optional) The number of callbacks to wait.<br />
///     Defaults to <c>1</c>
/// </param>
/// <param name="cancellationToken">
///     (optional) A <see cref="CancellationToken" /> to cancel waiting.<br />
///     Throws a <see cref="OperationCanceledException" /> if the token was canceled before the callback was executed.
/// </param>
/// <returns></returns>
Task<TValue[]> WaitAsync(Func<TValue, bool>? filter = null, int count = 1, CancellationToken? cancellationToken = null);

I would then start collecting the callbacks directly when IAwaitableCallback is created and this would allow the following workflow:

using var watcher = fileSystem.FileSystemWatcher.New("/");
watcher.IncludeSubdirectories = true;
watcher.EnableRaisingEvents = true;

const string fileName = "test.txt"

List<WatcherChangeTypes?> changes = [];

using var changeWatcher = fileSystem.Watcher.OnTriggered(x => {
    if (x.Path.EndsWith(fileName)) {
        changes.Add(x.ChangeType);
    }
});

..operate on file system..

const int timeoutInSeconds = 5 * 1000;
// count = 3 (Created -> Changed -> Deleted)
// Assumptions
await changeWatcher.WaitAsync(timeout: timeoutInSeconds, count: 3); // if timeout exhausts throw as usual
changes.FirstOrDefault().ShouldBe(WatcherChangeTypes.Created);
changes.LastOrDefault().ShouldBe(WatcherChangeTypes.Deleted);

In a synchronous scenario you could use the same workflow but call .Wait and it would block (we would no longer need the ExecuteWhileWaiting callbacks and could remove them in a future update).

What are your thoughts, @teneko?