UniTask cancelImmediately: true ordering question

[wjm9932]

Hello :)

I’m learning UniTask and I have a question about execution ordering when I cancel the token.

Here is a minimal example:

public class UniTaskTest : MonoBehaviour
{
private CancellationTokenSource cts;

void Start()
{
    cts = new CancellationTokenSource();
}

void Update()
{
    if (Input.GetKeyDown(KeyCode.S))
    {
        TestUniTask().Forget();
    }
}

void OnDestroy()
{
    cts.Dispose();
}

private async UniTask TestUniTask()
{
    cts.Cancel();
    cts = new CancellationTokenSource();

    Debug.Log("1");

    await UniTask.WaitForSeconds(10f, cancellationToken: cts.Token, cancelImmediately: true)
                 .SuppressCancellationThrow();

    Debug.Log("2");
}

}
Question:
If I press S again while the previous WaitForSeconds is still waiting, is it guaranteed that the logs will always be ordered like this?

1 2 1 2 (for two presses)

Or is it possible that the second call prints "1" and then the first call prints "2" (or even "2" appears before the second call’s "1") due to cancelImmediately: true and CancellationToken callbacks?

In other words, does cancelImmediately: true provide any ordering guarantees between concurrent calls, or can the continuations run in an interleaved order?

Thanks!

[tigran-sargsyan-w]

In this exact example, assuming TestUniTask() and cts.Cancel() are both called from Unity's main thread, the previous invocation should resume during cts.Cancel() before the new invocation reaches its Debug.Log("1").

With cancelImmediately: true, UniTask registers a callback on the CancellationToken. When:
cts.Cancel();
is called, that cancellation callback completes the pending UniTask immediately. Its continuation is then invoked as part of that completion.

Because you're also using:
.SuppressCancellationThrow()
the previous invocation continues past the await and executes:
Debug.Log("2");
before the new invocation proceeds to:

cts = new CancellationTokenSource();
Debug.Log("1");

So for two presses, with the second press happening while the first delay is pending, I would expect:

1
2
1
2

However, I would not treat cancelImmediately as a general synchronization/order guarantee between arbitrary concurrent async operations.

Its purpose is to change when cancellation is observed: immediately through CancellationToken.Register, instead of waiting for UniTask's next PlayerLoop check.

If cancellation could come from another thread, or if several independent async operations can race, their relative ordering should not be based on cancelImmediately.

If strict ordering is part of the application's logic, I would make that ordering explicit — for example by serializing the operations, awaiting the previous operation before starting the next one, or using a generation/version ID to ignore stale continuations.

So:

For this main-thread example: 1, 2, 1, 2 is the expected ordering.

As a general concurrency guarantee: no, cancelImmediately should not be used as one.