[🚀 Feature]: [dotnet][bidi] `IEventStream<>.ConfigureAwait()` call is ambiguous

[kevinoid]

Description

I noticed an ergonomic issue with the event streams added in #17349 (which are fantastic, by the way!) that seemed worth noting: When ConfigureAwait(bool) is called on IEventStream<> to control capturing context during disposal, it causes compile error CS0121 due to ambiguity between TaskAsyncEnumerableExtensions.ConfigureAwait(IAsyncDisposable, bool) and TaskAsyncEnumerableExtensions.ConfigureAwait<T>(IAsyncEnumerable<T>, bool).

This isn't a showstopper, since a cast to either type can be added to resolve the ambiguity. However, this seems less than ideal as it clutters the code for a common operation, and steepens the learning code as developers need to understand how to resolve the error initially and determine which cast to make.

Perhaps it would make sense to provide a .ConfigureAwait<T>(IEventStream<T>, bool) extension method which forwards to TaskAsyncEnumerableExtensions.ConfigureAwait<T>(IAsyncEnumerable<T>, bool) to avoid the ambiguity?

Have you considered any alternatives or workarounds?

No response

[selenium-ci]

@kevinoid, thank you for creating this issue. We will troubleshoot it as soon as we can.

Selenium Triage Team: remember to follow the Triage Guide

[kevinoid]

After thinking about this a bit more, resolving the ambiguity may not be advisable, since each has very different effects: TaskAsyncEnumerableExtensions.ConfigureAwait(IAsyncDisposable, bool) configures the behavior when the IEventStream<> is disposed, while TaskAsyncEnumerableExtensions.ConfigureAwait(IAsyncEnumerable, bool) configures how waits on Tasks returned by enumeration behave.

Perhaps separate extension methods (ConfigureAwaitDispose/ConfigureAwaitEnum) would make sense? I'm brainstorming, rather than advocating at the moment.

[nvborisenko]

My first thoughts Selenium shouldn't resolve it. Definitely this rare case looses elegance of await using. ConfigureAwait(false) - only for synchronization context (UI, ASP, Library author) - limited cases where an author is trying to be good developer... Thus extra typing... even ConfigureAwait(false)... I don't find this ambiguous situation as something bad.

I don't see potential improvements at Selenium side.

Tried be good developer:

var stream = await bidi.Log.EntryAdded.StreamAsync().ConfigureAwait(false);

await using (((IAsyncDisposable)stream).ConfigureAwait(false))
{
    await foreach (var l in ((IAsyncEnumerable<EntryAddedEventArgs>)stream).ConfigureAwait(false))
    {
          break;
    }
}

Doesn't look ugly IMHO.

[kevinoid]

I think you are probably right. It seems a bit verbose to me, but it's easy enough for users to define their own extension method if that's what they'd prefer. Thanks for thinking through it, I appreciate the thoughtful discussion.

[nvborisenko]

I was thinking more about IEventStream<>, and seems we can easily expose raw IAsyncEnumerable<> (where disposal of enumerator will unsubscribe on wire). Potentially, it will significantly simplify API without loosing of functionality. Yes, continuous enumeration over the disposed stream becomes impossible, but it is acceptable: just create new stream.

So full usage pattern becomes:

var stream = await bidi.Log.EntryAdded.StreamAsync();

DoSomething();

await foreach (var log in stream)
{
    break;  // this is end of enumeration, we can unsubscribe internally
}

No explicit disposal required via await using, now it becomes natural from end user point of view, and, hopefully, easy from internal implementation.

[nvborisenko]

Nicely done, proposed the PR. I really like this simplification!

@kevinoid please review whether proposed changes simplify your syntax too.