Consider adding ConfigureAwait(false)

[roji]

After our discussion, it seems that the omission of ConfigureAwait(false) doesn't actually prevent all race conditions which could be produced in a UI application. In other words, if a user clicks twice on a button, then two SaveChangeAsync() invocations could be attempted at the same time, resulting in an exception. The only way around this would be for the user to make sure their application doesn't call EF APIs while another call is still in progress (i.e. by graying out buttons before starting the first request).

If ConfigureAwait(false) is added, then it's still an open question whether user callbacks should be executed in the user's synchronization context or in the thread pool (e.g. setting properties while materializing entities).

There's a good possibility this would be a breaking change - to be evaluated.

Related to #10914.

[ajcvickers]

We want to reconsider this and talk to people to understand better whether we should do it before...

[roji]

Any reason for closing this, especially now that the 3.0 milestone has been announced?

It's true that there's still the open question of calling user callbacks (i.e. entity properties during materialization) with the synchronization or not, but at the very least I imagine there's quite a bit of internal EF Core code which could be executed on the thread pool instead of on the UI thread?

[roji]

Note: this was done in #10164