Tasks do not complete in the order they were started

[JohannesPaivinen]

Hello,

We are using UniTask to run visualizations in our puzzle game and have observed an issue when running multiple tasks with equal duration. They do not complete in the order they started. For example, this code

   void Start()
    {
        for (var i = 0; i < 3; i++)
            UpdateAsync(i).Forget();
    }

    private async UniTask UpdateAsync(int id)
    {
        Debug.Log($"{id} started");
        await UniTask.Delay(500);
        Debug.Log($"{id} completed");
    }

Would start tasks 0-1-2 but complete 0-2-1.

This behavior is caused by the way UniTask manages player loop items in PlayerLoopRunner. When an item is completed, it's removed from the item array by swapping, which alters the order in which the remaining items are updated.

We would prefer that the item would be removed by copying, which would retain the order of the other items.

Would you consider making this behavior toggleable by a setting in UniTask?

Or is there another way to accomplish the same result?

[SERAP-KEREM]

This is expected behavior in the current UniTask implementation and not an issue in your code.

Why completion order can differ

All three UniTask.Delay(500) calls are registered in PlayerLoopRunner in registration order (0, 1, 2). However, when a task completes, its IPlayerLoopItem is removed from the internal array using a swap-remove (tail swap) strategy for O(1) removal and minimal overhead.

Because of this, when one item completes, the last element in the array is moved into its place. This can change the iteration order of the remaining active items within the same frame, which may result in completion logs appearing as 0, 2, 1 even though registration order was 0, 1, 2.

This behavior has been acknowledged in discussions such as #453, and the general design choice is that UniTask does not guarantee FIFO ordering of completion callbacks for parallelly running tasks. Related discussions like #701 also mention potential FIFO-preserving approaches, but the current implementation prioritizes performance and allocation-free updates.

About ordering guarantees

UniTask does not guarantee that tasks started earlier will complete earlier when they are running in parallel, even if they have identical delay durations.

This is especially true for Delay, which is scheduled on the PlayerLoop and resolved per-frame rather than being strictly queued in a deterministic completion order.

About adding a toggle

A toggle for FIFO-preserving removal is unlikely to be introduced, since it would add branching and an alternative execution path for a behavior that is intentionally not guaranteed today. If strict ordering is required, it should be handled at the application level.

Recommended approaches

If strict sequential order is required (common in puzzle/game visual flows), the simplest solution is to await sequentially:

async UniTaskVoid Start()
{
    for (var i = 0; i < 3; i++)
        await UpdateAsync(i);
}

If work needs to run in parallel but results must be processed in order, you can separate execution from presentation by collecting tasks and then consuming them in sequence:

var tasks = new UniTask[3];

for (int i = 0; i < 3; i++)
    tasks[i] = UpdateAsync(i);

await UniTask.WhenAll(tasks);

Then apply any ordered presentation logic after completion if needed.

Summary

• This behavior is expected due to swap-remove optimization in PlayerLoopRunner
• UniTask does not guarantee FIFO completion order for concurrent operations
• If ordering matters, it should be enforced explicitly at the application level rather than relying on internal scheduling

Hope this clarifies the behavior.