PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

private async Task ProcessEventsLoopAsync()
{
    while (await _pendingEvents.Reader.WaitToReadAsync().ConfigureAwait(false))
    {
        try
        {
            var result = await _pendingEvents.Reader.ReadAsync().ConfigureAwait(false);

            if (_eventHandlers.TryGetValue(result.Method, out var eventHandlers))
            {
                if (eventHandlers is not null)

_receivingMessageTask = Task.Run(async () => await ReceiveMessagesLoopAsync(_receiveMessagesCancellationTokenSource.Token));
_eventEmitterTask = Task.Run(ProcessEventsLoopAsync);

PR Code Suggestions ✨

Explore these optional code suggestions:

-await _pendingEvents.Writer.WriteAsync(messageEvent).ConfigureAwait(false);
+try {
+    await _pendingEvents.Writer.WriteAsync(messageEvent).ConfigureAwait(false);
+} catch (ChannelClosedException) {
+    // Handle or log channel closed error
+}

-while (await _pendingEvents.Reader.WaitToReadAsync().ConfigureAwait(false))
+while (await _pendingEvents.Reader.WaitToReadAsync(_receiveMessagesCancellationTokenSource.Token).ConfigureAwait(false))
 {
     try
     {
-        var result = await _pendingEvents.Reader.ReadAsync().ConfigureAwait(false);
+        var result = await _pendingEvents.Reader.ReadAsync(_receiveMessagesCancellationTokenSource.Token).ConfigureAwait(false);

 public async Task<TResult> ExecuteCommandAsync<TCommand, TResult>(TCommand command, CommandOptions? options)
     where TCommand : Command
 {
+    ArgumentNullException.ThrowIfNull(command, nameof(command));
     var jsonElement = await ExecuteCommandCoreAsync(command, options).ConfigureAwait(false);

Nice changes! How does this affect performance/memory?

Didn't test it accurately without remote-end party. But I don't expect performance improvement here.

Hm, now I am struggled: do we really want to introduce new dependency instead of BlockingCollection<> which just works? Given that a good library is a library without dependencies, then we should provide strong arguments why we need Channels.

BlockingCollection<> is bounded to a maximum size, and is blocking (probably why we needed to mess with TaskFactory in the existing code).

Channel<T> is also much more low-level and is faster (performance improvements shown in the recent Nick Chapsas video and the older Toub blog post).

Additionally, this only adds a new dependency on older TFMs. I don't know the stats about how many people use the .NET 8 version vs. the .NET Standard version, but the kinds of blockers which prevent upgrades to modern .NET are not usually present in code that uses Selenium. For this reason, a dependency that only exists on older .NET versions seems less critical.

Thanks @nvborisenko for contribution. I decided (8 Feb) to not introduce new dependency to fix mimic issue/improvement. In case of any issues, please came in here.