Deadlock occurs all the time if MvxAppStart.ApplicationStartup(...) has an await

[evgenyvalavin]

🐛 Bug Report

MvxAppStart.ApplicationStartup(...) is a virtual method returning a Task. It means anyone can override the method and add any code, including asynchronous code.
There're 6 await keywords in the MvxAppStart and no .ConfigureAwait(false) to prevent deadlocks.
I don't see why .ConfigureAwait(false) must not be added to each method with await.
I come across this deadlock over time over and over again and it always takes time to investigate.

Expected behavior

No deadlock occurs if asynchronous code with an await is added to ApplicationStartup(...)

Reproduction steps

1. Add await Task.Delay(1_000).ConfigureAwait(false) or just await Task.Delay(1_000) to ApplicationStartup(...) to cause a deadlock.

Deadlock is caused by manually retrieving an awaiter and getting the result in
StartAsync(hint).GetAwaiter().GetResult();

Configuration

Version: 9.0.2

Platform:

• 📱 iOS

[entdark]

Maybe it's actually this: #4364?

[evgenyvalavin]

I don't think so. The deadlock is reproducible on MvvmCross 7.1.2.

The issue have been here since Adjusting startup behaviour commit when .ConfigureAwait(false) was missed. I believe starting from 6.2.0-beta1