You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
Add await Task.Delay(1_000).ConfigureAwait(false) or just await Task.Delay(1_000) to ApplicationStartup(...) to cause a deadlock.
馃悰 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
await Task.Delay(1_000).ConfigureAwait(false)
or justawait 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:
The text was updated successfully, but these errors were encountered: