`PutObject_Test9` sometimes fails during CI/CD build about minio-dotnet HOT 2 CLOSED

I think I see the problem... Reporting is done using the System.Progress<T> class. As can be read here these events are send to the synchronization context of the Progress<T> object during construction. This is the actual call that is being invoked when you call Progress.Report(...):

/// <summary>Reports a progress change.</summary>
/// <param name="value">The value of the updated progress.</param>
void IProgress<T>.Report(T value) { OnReport(value); }

/// <summary>Reports a progress change.</summary>
/// <param name="value">The value of the updated progress.</param>
protected virtual void OnReport(T value)
{
    // If there's no handler, don't bother going through the sync context.
    // Inside the callback, we'll need to check again, in case
    // an event handler is removed between now and then.
    Action<T>? handler = _handler;
    EventHandler<T>? changedEvent = ProgressChanged;
    if (handler != null || changedEvent != null)
    {
        // Post the processing to the sync context.
        // (If T is a value type, it will get boxed here.)
        _synchronizationContext.Post(_invokeHandlers, value);
    }
}

As you can see, it will perform a Post(...) on the synchronization context and that means that it will be invoked asynchronously. A Post(...) is a kind of fire-and-forget mechanism. So if your code runs fast, then the progress update is still in the queue and waiting to be dispatched, but the upload is already finished.

from minio-dotnet.

The reason that MS decided to use asynchronous posting of events in System.Progress<T> is probably, because progress is often used to provide feedback to the user. Most UI frameworks (at least WinForms and WPF) require that all UI updates are done on the main-thread. Because progress updates are normally not needed to be done in real-time (it doesn't matter that a progress updates is a few milliseconds late), using the SynchronizationContext is very convenient in UI applications.

The reason that they choose to Post() instead of Send() is not to block the caller. If they would have used Send(), then the call will be called synchronously on the progress thread and that would block processing and slow it down.

In a unit-test, there is no need for thread-synchronisation and using a callback that is invoked on an arbitrary thread is just fine.

from minio-dotnet.