-1

We have code like this and seem to get inconstant results(meaning that sometimes no results are returned, they are all 0 counts!) when called in production. I was wondering would the await calls after the WaitAll causes issues as it seems like we should maybe be calling .Result?

For example when we call the below, should we be calling .Result instead.

Destinations = await arrivalsDestinations,

After doing the Task.WhenAll

Example code here:

var inHouseDestinations = GetDestinationPax(destinations, PaxPassengerLocation.InHouse, destinationFacet);
var arrivalsDestinations = GetDestinationPax(destinations, PaxPassengerLocation.Arrivals, destinationFacet);
var arrivalsTomorrowDestinations = GetDestinationPax(destinations, PaxPassengerLocation.ArrivalsTomorrow, destinationFacet);
var departuresDestinations = GetDestinationPax(destinations, PaxPassengerLocation.Departures, destinationFacet);

await Task.WhenAll(
        inHouseDestinations, arrivalsDestinations, arrivalsTomorrowDestinations, departuresDestinations);

var arrivalsSummary = new PaxDataSummary()
{
    PassengerLocation = PaxPassengerLocation.Arrivals,
    Destinations = await arrivalsDestinations,
    Resorts = await arrivalsResorts,
    Properties = await arrivalsProperties
};
Andrew
  • 2,571
  • 2
  • 31
  • 56
  • 1
    await calls after the WaitAll or WhenAll? What does inconstant mean? – shingo Oct 25 '22 at 08:15
  • The results for awaiting multiple tasks that all return the same type (in your example, I assume they all return `Destinations`) are returned from the `await Task.WhenAll()` in an array: `Destination[] destinations = await Task.WhenAll(inHouseDestinations, ...)`. A think you should be using the return values that way. – Matthew Watson Oct 25 '22 at 08:16
  • What do you mean @MatthewWatson? return value which way? – Andrew Oct 25 '22 at 08:21
  • 3
    Generally you want to avoid calling `.Result` at the best of times. Not only does it defeat the purpose of `Task` but, depending on the application type (I'm looking at you ASP.NET classic). you are at risk of encountering a **thread deadlock!** _[Goodness, tell me more...](https://blog.stephencleary.com/2012/07/dont-block-on-async-code.html)_ –  Oct 25 '22 at 08:22
  • The results have supposedly all be completed in the WhenAll so it seems that its ok to still call await after the fact and not call .Result. – Andrew Oct 25 '22 at 08:24
  • 2
    @Andrew I'm saying that the results of the tasks are ALREADY returned in an array as the return value from `Task.WhenAll()` so you can use the results from that array instead of calling `await` or `.Result` again. (Assuming that the tasks all return the same result type) – Matthew Watson Oct 25 '22 at 08:24
  • Ok thanks @MatthewWatson, we would not want to dump all results, we would need separate ones, this would mean that we have to just get each result set from array index e.g. [0], [1]...etc!? – Andrew Oct 25 '22 at 08:26
  • 2
    Yes, that's correct. But I note that you're only actually using the results from `arrivalsDestinations` in your sample code. Is that correct, or is that just a transcription error? – Matthew Watson Oct 25 '22 at 08:27
  • Yes correct there was more blocks of other calls and I just pulled one block out. Thanks for the help – Andrew Oct 25 '22 at 08:31

1 Answers1

0

Code that you have with await more correct )You can use both variant, but .Result blocks the calling thread until the asynchronous operation is complete; it is equivalent to calling the Wait method.

Nastya
  • 101
  • 1
  • 1
  • 8
  • Since it first went thourgh WhenAll, calling `.Result` won't block more or less than using await. The real difference is in how Exceptions are handled: `await` will unwrap the potential `AggregateException` while `.Result` will return it as-is. – bkqc May 24 '23 at 17:19