Monitor OccurredEvents ordering

[JordanGottardoImagicle]

Description

Monitor OccurredEvents ordering seems to be random and does not reflect the order in which events were raised.

Complete minimal example reproducing the issue

public class MyClass
{
    public event EventHandler FirstEvent;
    public event EventHandler SecondEvent;
    public event EventHandler ThirdEvent;

    public void RaiseFirstEvent()
    {
        FirstEvent?.Invoke(this, EventArgs.Empty);
    }

    public void RaiseSecondEvent()
    {
        SecondEvent?.Invoke(this, EventArgs.Empty);
    }

    public void RaiseThirdEvent()
    {
        ThirdEvent?.Invoke(this, EventArgs.Empty);
    }
}

[Test]
public void Test()
{
    var myObj = new MyClass();

    using (var monitor = myObj.Monitor())
    {
        myObj.RaiseFirstEvent();
        myObj.RaiseSecondEvent();
        myObj.RaiseThirdEvent();

        monitor.OccurredEvents[0].EventName.Should().Be(nameof(myObj.FirstEvent));
        monitor.OccurredEvents[1].EventName.Should().Be(nameof(myObj.SecondEvent));
        monitor.OccurredEvents[2].EventName.Should().Be(nameof(myObj.ThirdEvent));
    }
}

Expected behavior:

OccurredEvents ordering should be the same as the raised events

Actual behavior:

OccurredEvents ordering is random, and changes with every run

Versions

I'm using FluentAssertions 5.6.0.
.NET Framework version 4.8.

[MullerWasHere]

I managed to reproduce this issue only on .NET Framework. The "culprit", so to speak, is the precision of DateTime.Ticks used in EventRecorder.

fluentassertions/Src/FluentAssertions/Events/EventMonitor.cs

Lines 46 to 56 in b8d6ac2

	get
	{
	IEnumerable<OccurredEvent> query =
	from eventName in recorderMap.Keys
	let recording = GetRecordingFor(eventName)
	from @event in recording
	orderby @event.TimestampUtc
	select @event;
	return query.ToArray();
	}

This wrong behavior might still happen on .NET Core onwards given a lot of method calls but is rarer due to dotnet/coreclr#9736.

I'm not sure what an elegant solution might look like. BlockingCollection<EventRecorder> could be moved up to EventMonitor from EventRecorder and act as the de facto list for occurred events for all child EventRecorders, backed by an object acting as a lock whenever an event is raised.

Let me know what you think.

[dennisdoomen]

Thank you for digging into this. I think what you're suggesting is one way of doing it. Another might be a thread-safe counter owned by the EventMonitor class that is used to assign unique incrementing numbers to each OccurredEvent