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?

[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?
}

[timcassell]

Like this:

using var _ = cancellationToken.Register(() => _completionSource.TrySetCanceled());

[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? 😅