WhenAll exits early when any task has an exception

[all-iver]

It seems as though WhenAll immediately fails with an exception if any awaited task throws an exception, instead of waiting for all the tasks to complete and then throwing the exception. I believe this is different than normal Task behavior which would wait until all tasks are completed regardless of whether some of them failed.

This was unexpected behavior for me because I am expecting some tasks to fail occasionally, but I still need to know that all tasks are done before continuing. I understand from #335 that WhenAll doesn't store the exceptions for individual tasks, but I think it should not convert to WhenAny just because one task failed...perhaps it could store the first exception that happened and then re-throw that when all tasks are done?

Or, is there some way I'm missing to wait for all tasks to complete regardless of failure?

[neuecc]

Yes, the reason WhenAll behaves differently than Task.WhenAll is due to a failure in my initial design.
I would like to fix it, but am having trouble thinking of a way to do so because it would break compatibility.

[timcassell]

If it helps, I recently solved this problem in my promise library by adding Promise.AllSettled to match the javascript method. You could do the same by adding WhenAllSettled.

[andreiagmu]

Has anyone checked out this solution? (by @adammyhre)
https://gist.github.com/adammyhre/40e7c968edda098fdebb2adbe806c911

Source, see Important Notes 4) in the video description:
https://www.youtube.com/watch?v=OlNJ2GkaPTE

[hmkc]

It might be possible to convert UniTask to Task using AsTask(), then use Task.WhenAll() to replace UniTask.WhenAll()

[github-actions]

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 30 days.

[RichardWepner]

@neuecc: It wouldn't be very elegant, but a fix could be introduced and put behind a #define check. This is not very elegant, since on the one hand the user would need to define this in the project settings (and to keep compatibility, this would need to become a setup step), and if the code changes required for this in the library are huge, then this would reduce the maintainability.

Out of curiosity, what are roughly the changes you'd need to perform in the library to fix this?

[neuecc]

I will never change behavior using #define.
If you want to add it, you should prepare it as a separate method name and then use an Analyzer to prohibit the conventional WhenAll.
Implementing it yoruself should only require small adjustments if you reference the existing implementation.

[RichardWepner]

I didn't say it was a good suggestion, but I wanted to mention it for the sake of completeness.

[ruben-ivre]

In my case, I've just suffered a bug caused by WhenAll finishing before expected due to some task faulting which let some other tasks start after it and caused overlapping issues.

I understand the fear to make such a breaking change in WhenAll, but in my humble opinion, you shouldn't consider it a breaking change, but a long-needed fix. In the end, the name is pretty clear, WhenAll, not WhenAllOrFault, and also it's the default behavior on the .Net counterpart.

And If there's anyone out there relying on this WhenAll breaking-on-fault behavior, well, they're not using a feature but exploiting a bug, so, yes, I do think this should be fixed and those users that are exploiting this bug will suffer issues when updating, but, overall, there will many more users benefiting from the fix than relying on the bug.

[yasirkula]

I like the tuple approach a lot ((result1, result2) = await (unitask1, unitask2)). It would've been nice to have a consistent experience with Task.WhenAll while continuing to use this tuple approach. At the moment, we need to rely on UniTaskHelpers which is not as convenient.

[johntday]

What is the recommended approach from Cysharp ?

[imniko]

Amazing to see this issue is not handled for more almost 3 year now.

[RichardWepner]

Amazing to see this issue is not handled for more almost 3 year now.

@imniko: @neuecc was responding already that they have difficulties coming up with a good solution to this. If you're interested in this being fixed, it might be helpful if you could take a code that's currently present and present a solution to this, possibly through a Pull Request (i.e. with the solution being implemented already in a verifiable/testable form).