Best practise for using UniTask.WhenAny?

[OrionFive]

Hi, I've noticed that using WhenAny systematically creates leaked tasks:

var taskA = buttonA.onClick.OnInvokeAsync(cancellationToken);
var taskB = buttonB.onClick.OnInvokeAsync(cancellationToken);
await UniTask.WhenAny(taskA, taskB);

When either event happens, the other task stays pending until the cancellationToken is triggered.
Creating a new merged cancellationToken for every case of WhenAny and canceling it afterward seems tedious and error-prone.

Is there a way to dissolve the tasks after the await?
Is there a simple pattern to deal with these cases gracefully?

[BoysheO]

Maybe unirx can help you.

await buttonA.onClick.AsObservable()
    .Amb(buttonB.onClick.AsObservable())
    .First();

[OrionFive]

Thanks for this response. But is there really no better way than require another framework?
It is fairly compact, but hard to read.
Also, does this really make sure all tasks are dissolved when any of them finishes?

[Thundernerd]

Isn't this default C# behavior? WhenAny is just a construct to wait for many but opt out early if one of them completes. If it would automatically cancel the remaining tasks I would suspect that could lead to a lot of unexpected behavior.

My suggestion would be that if you want the other tasks to be canceled then you do indeed cancel the token.

[OrionFive]

Is it really unexpected to cancel the other tasks? I don't think you can easily reuse them. So when they trigger, it does nothing. When I got started with this, I always expected they would get canceled or "disappear", like a Unity Coroutine would when the component it runs on is destroyed.

I've been thinking about writing a custom WhenAny method. But since the token used for the tasks has to be a combined token, I couldn't find a clean way to make it work.

I just want to avoid the huge messy chunk of code that is required every time. Because apart from that UniTask makes for clean and easy to read code, and this ruins that.

[Blackclaws]

Yes its unexpected. If you take a look at the original Task.WhenAny documentation: https://learn.microsoft.com/en-us/dotnet/api/system.threading.tasks.task.whenany?view=net-7.0

You basically get a statement that says: "Creates a task that will complete when any of the supplied tasks have completed."

Nothing in the spec says anything about cancelling the other tasks when WhenAny has returned and that would be very unexpected behaviour indeed.

Since there is no way to cancel an inflight UniTask unless you cancel it at the source (which might or might not accept a CancellationToken) there is also no way for any external extension method to do what you are asking.

[alijaya]

any update on this?

[krisrok]

So to actually cancel the remaining task(s) you'd have to create a new token source and cancel it afterwards, right? Something like this:

using var cancellationTokenSource = CancellationTokenSource.CreateLinkedTokenSource(cancellationToken);
cancellationToken = cancellationTokenSource.Token;
var taskA = buttonA.onClick.OnInvokeAsync(cancellationToken);
var taskB = buttonB.onClick.OnInvokeAsync(cancellationToken);
await UniTask.WhenAny(taskA, taskB);
cancellationTokenSource.Cancel();

Does not seem overly verbose to me but maybe there's something I'm missing?

[OrionFive]

I'm running the whole application logic as a chain of tasks. Pseudo code:

await LoadAssets(token);
while(whatever) {
  await AskUserAboutX(token);
  await PlayFeedback(token);
}
await ReleaseResources(token);

So at any given moment, some task is running, usually waiting for a resource or the user.
@Blackclaws, can you elaborate the UniTaskCompletionSource.Task solution? Is it the same as @krisrok suggests?

[Blackclaws]

Right, we're doing the same. However in the case where you have a screen with two possible buttons, modelling that as a series of asynchronous awaits like you're doing with the WhenAny starts making less sense.

Interacting with multiple possibilities is usually more event based. What we do is the following:

When a User navigates to a screen, we start up that screen and the screen returns a UniTask that we can await in the parent screen.
However unless its something simple like a dialog that can only have one possible interaction, we do not return a composition of UniTasks like you do. What we do instead is the following:

UniTaskCompletionSource _completionSource;

defined at the class level.

UniTask ShowScreen() {
   _completionSource.TrySetCanceled();
   _completionSource = new();
   /* Screen show logic here */
   return _completionSource.Task;
}

or if you need to do work afterwards:

async UniTask ShowScreen() {
   _completionSource.TrySetCanceled();
   _completionSource = new();
   /* Screen show logic here */
   await _completionSource.Task;
  /* more work here */
}

you can then work with your screen as normal and Trigger the completion of your Source asynchronously from within your event handlers like this:

void OnButtonOneClicked() {
   _completionSource.TrySetResult();
}
void OnButtonTwoClicked() {
   _completionSource.TrySetResult();
}

I've omitted the logic to add/remove event handlers for the buttons. But that's the gist of it. This way you only have one logical task that you are awaiting and the completion of that task is left to code that deals with Events, which is what button presses are in the end.

This is by the way what OnInvokeAsync does internally as well, it creates a completion source that is set to completed once the button is clicked. Actually pretty much any asynchronous code in the end comes back to something like this where an event/callback from somewhere sets a completion source/task result.

[krisrok]

Ah that's an interesting approach.

And to build on that you could also use the generic version of the class and deliver a result with completion, e.g.:

enum MyResult { Confirmed, Cancelled };
UniTaskCompletionSource<MyResult> _completionSource;
[...]
void OnButtonOneClicked() {
   _completionSource.TrySetResult(MyResult.Confirmed);
}
void OnButtonTwoClicked() {
   _completionSource.TrySetResult(MyResult.Cancelled);
}

[Blackclaws]

Yes exactly. I just showed the barebones idea but this is something we use heavily throughout our codebase whenever we defer a longer running process that relies on external events to trigger a callback.

[OrionFive]

Nice pattern! That does neatly circumvent the issue of having to cancel awaiting events. Thanks for sharing the idea.