.ConfigureAwait(false) missing in DataPortal access async methods

[bil-bal]

Hi, we had a case where the UI (using WPF) was blocking for a few seconds at the end of fetching a BusinessListBase through IDataPortal<T>.FetchAsync(). We thought the binding of the list would cause the blocking, but we verified it with the following snippet in the BusinessObjectViewModel<T>

async Task Foo(Func<Task<T>> factory)
{
    var model = await factory();
    Model = model;
}

that the blocking happens before Model is set. While going through the csla source code, we found that there were no .ConfigureAwait(false) applied in the DataPortal access async methods. Is there a reason for this?

[rockfordlhotka]

iirc, the use of ConfigureAwait(false) on the client side, especially for WinForms/WPF, is problematic because it pushes a lot of work onto the average UI developer. The reason being, that results may (and often do) come back on different threads and/or outside the synchronization context of the UI - forcing you to used UI framework appropriate techniques to shift the result back onto the UI thread.

Basically, again iirc, it prevents the use of data binding in most scenarios.

[rockfordlhotka]

Doesn't that only apply to BO's which do not get over the wire?

It should apply in all cases. The client-side data portal tries to make it transparent as to whether you are using a local or remote data portal for your logical server.

My recollection is that there are only a couple scenarios in WinForms (maybe WPF?) where there are some limitations on whether the logical server-side code can or can't use async methods. It has been years. I'm pretty sure the limitations are documented in the Using CSLA 4 ebooks.

[rockfordlhotka]

But the context flows down the await chain until it hits (ultimately) the http call. But the await there also captures the UI context which means the whole deserialization stuff happens on the UI again instead of a background thread. That causes the UI to lock at that point already instead when returning from the factory() call. Because the context is captured for each await in the chain and not at the most top one.

Ahh, good point.

I'm not sure there's a generic way to resolve that - a way that works across all client-side UI frameworks (console, winforms, wpf, aspnetcore, blazor (server/wasm)).

I'm also not sure it is a "CSLA problem", because this would happen with any code that calls an http service unless the UI developer intentionally created a background thread and then shifted the result back onto the UI thread.

That said - if there was a way to generically and reliably solve this across all UI frameworks, that'd be pretty wonderful.

[ossendorf-at-hoelscher]

Yeah. The problematic ones are the "in memory" clients. There it could be a problem. But as long as there is no real "await" it should be completed synchronously.
In this case CSLA is abstracting away the http call so I can't say: Yeah I know I don't need the context here and use ConfigureAwait(false).

Maybe a new setting to configure the client side dataportals ConfigureAwait parameter through the portal could solve that? 🤔

[rockfordlhotka]

We also can't assume http. The data portal can use any network transport, and there are channels for grpc and rabbitmq as well.

[StefanOssendorf]

It doesn't matter what kind of transport when it goes over the wire. In that regard the handling is luckily the same.