Event constraining extensions WithArgs and WithSender will return matching events #1321
Conversation
|
|
||
| public IEnumerator<OccurredEvent> GetEnumerator() | ||
| { | ||
| foreach (RecordedEvent @event in raisedEvents.ToArray()) |
There was a problem hiding this comment.
Should there be a lock around raisedEvent.ToArray()?
There was a problem hiding this comment.
No, because it's a BlockingCollection. Wondering if I should change the name of field to make that clearer.
There was a problem hiding this comment.
I'm asking since the OccurredEvents property is iterating the collection inside a lock.
Peeking in the source it seems that both GetEnumerator() and ToArray() on a BlockingCollection forwards the calls to the underlying ConcurrentQueue.
https://source.dot.net/#System.Private.CoreLib/ConcurrentQueue.cs,ceb5564a9e120593,references
https://source.dot.net/#System.Private.CoreLib/ConcurrentQueue.cs,956829c6ddc21632,references
From ConcurrentQueue.GetEnumerator
The enumerator is safe to use concurrently with reads from and writes to the queue
To summarize, as I read the documentation neither calls to GetEnumerator() nor ToArray() needs to be surrounded by a lock.
932a7a0 to
f112c03
Compare
jnyrup
left a comment
There was a problem hiding this comment.
Awesome work 👍
(Also gave me a reason to get a better grasp of this part of FA)
…ching events * Several event raising assertion APIs will return an `IEventRecording` instead of `IEventRecorder` * The classes `EventMonitor` and `RecordedEvent` are now treated as `internal` code * Renamed method `GetEventRecorder` of interface `IMonitor` to `GetRecordingFor` and will return `IEventRecording`
WithArgsandWithSenderwill return only the events that match the constraintsIEventRecordinginstead ofIEventRecorderEventMonitorandRecordedEventare now treated asinternalcodeGetEventRecorderof interfaceIMonitortoGetRecordingForand will returnIEventRecordingFixes #337