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]

It's usually various tasks. So that's gonna be tricky.

[Blackclaws]

I actually never had to use WhenAny before so I'm a bit curious about your use cases. For buttons its usually simpler to just attach an event handler that triggers something than to wait for a button press like you are doing. The reason is that button presses are more event like than asynchronous processing.

If you are waiting for any button press another solution would be to just return a UniTaskCompletionSource.Task and then set its status to Completed when either of the buttons is pressed. That's what we do in a lot of cases where we have to wait for a certain UI screen to be dismissed for example.

[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.

[MeisterDerMagie]

Interesting approach, but I wonder how you pass a CancellationToken to the _completionSource.
Let's take the example of @Blackclaws but add a CancellationToken parameter:

async UniTask ShowScreen(CancellationToken cancellationToken) {
   _completionSource.TrySetCanceled();
   _completionSource = new();

   //How to stop the await if the passed cancellationToken was cancelled? I can't find a solution for this.
   await _completionSource.Task; 


   //completionSource.Task.AttachExternalCancellation(cancellationToken) doesn't seem to work. Why?
}

[Blackclaws]

Just check if the cancellationToken.IsCancellationRequested and don't await then. Once you await cancelling the completion source will throw a Task Cancelled Exception at the await as intended

…

On March 26, 2025 3:12:45 PM GMT+01:00, Meister der Magie ***@***.***> wrote: Interesting approach, but I wonder how you pass a CancellationToken to the _completionSource. Let's take the example of @Blackclaws but add a CancellationToken parameter: ´´´ async UniTask ShowScreen(CancellationToken cancellationToken) { _completionSource.TrySetCanceled(); _completionSource = new(); /* Screen show logic here */ await _completionSource.Task; //How to stop the await if the passed cancellationToken was cancelled? I can't find a solution for this. /* more work here */ } ´´´ -- Reply to this email directly or view it on GitHub: #389 (reply in thread) You are receiving this because you were mentioned. Message ID: ***@***.***>

[MeisterDerMagie]

Thank you for the quick answer, really appreciate it!
But I don't quite get it. What if the token is cancelled while awaiting the completionSource.Task? This task doesn't know about my cancellationToken, how would it throw an exception? I can't find a way to pass my token to the completion source. Do you know what I mean? 😅

[tigran-sargsyan-w]

UniTask.WhenAny does not cancel the “losers” by design (same as Task.WhenAny). So those pending OnInvokeAsync tasks keep listening until you cancel or dispose them yourself. The clean pattern is: create a linked CancellationTokenSource, start both awaits with that token and keep the event handlers so you can dispose the one that didn’t win; right after WhenAny returns, cancel the linked CTS to stop the other await and dispose its handler. This avoids dangling subscriptions and makes the intent explicit.

using Cysharp.Threading.Tasks;
using Cysharp.Threading.Tasks.Triggers;
using System.Threading;
using UnityEngine.UI;

// waits for either A or B click, returns 0 for A, 1 for B
public static async UniTask<int> WaitAnyClick(Button buttonA, Button buttonB, CancellationToken token)
{
    // propagate caller’s token but also allow us to cancel the loser
    using var cts = CancellationTokenSource.CreateLinkedTokenSource(token);

    // keep handlers so we can dispose (unsubscribe) the one that didn't win
    using var hA = buttonA.GetAsyncClickEventHandler(cts.Token);
    using var hB = buttonB.GetAsyncClickEventHandler(cts.Token);

    // WhenAny over typeless UniTask returns the winner index
    var winner = await UniTask.WhenAny(hA.OnClickAsync(), hB.OnClickAsync()); // 0 or 1

    // stop the other await and release its subscription immediately
    cts.Cancel();

    return winner;
}

Why this works: WhenAny only tells you who finished first; it never cancels others by itself (that would be surprising for callers and is not how .NET’s Task.WhenAny behaves). Passing a linked token ensures both awaits can be cancelled as a group after the winner is known. Holding the AsyncUnityEventHandler instances and wrapping them in using makes sure the underlying UnityEvent subscription is disposed deterministically, so you don’t keep listening after you’re done. If you prefer constructing the handler explicitly you can also do new AsyncUnityEventHandler(button.onClick, cts.Token, callOnce: true) and call OnInvokeAsync() on it — same idea.

Two small tips:

• If your awaits can throw OperationCanceledException and you don’t want to catch it, you can finish the deepest awaited tasks with. SuppressCancellationThrow() and check the returned flag instead; use it locally and sparingly.
• When you can’t pass your token into the original task (e.g. you’re awaiting a UniTaskCompletionSource), you can still cancel the await via AttachExternalCancellation: await _completionSource.Task.AttachExternalCancellation(cts.Token); It doesn’t cancel the source itself, it just makes the await complete as canceled when your token fires. Alternatively, race it with UniTask.WaitUntilCanceled(cts.Token) using WhenAny.

Relevant docs if you want to double-check the signatures/behavior: WhenAny over UniTask returns the winner index; GetAsyncClickEventHandler/AsyncUnityEventHandler let you manage and dispose uGUI event subscriptions; and .NET’s Task.WhenAny spec explains why “auto-cancel the others” would be unexpected. ✅