ChildDataPortal.Update yield 'Cannot wait on monitors on this runtime'

[clodewyks]

Hello Again!

We are experiencing a very similar issue to the previous discussion where it appears the sync operations which call .Wait() are being used instead of the async method.

Our app uses offline and online modes through ApplicationContext.IsOffline. When offline the Data Access Layer is storing to IndexedDB, when online it stores to SQL via the remote dataportal.

We are experiencing an issue when saving a child object from within its parents DataPortal.Insert, it appears the synchronous Update method is being called on ChildDataPortal instead of UpdateAsync only when offline, when the app is online and saving to SQL it works perfectly.

Here is the parent insert:

[Insert]
private async Task InsertClient([Inject] IClientDAL dataAccess, [Inject] IChildDataPortal<ClientBeneficiaries> beneficiariesDP)
{
    LoadProperty(ClientIdProperty, await dataAccess.InsertClient(LoadCientDTO()));

    if (ClientId == 0)
        throw new Exception("Data was not inserted successfully.");

     if (FieldManager.FieldExists(BeneficiariesProperty))
         await beneficiariesDP.UpdateChildAsync(ReadProperty(BeneficiariesProperty), this);
}

And here is the Update method on the ClientBeneficiary object:

[InsertChild]
async Task InsertClientBeneficiary(Client client, [Inject] IBeneficiaryDAL beneficiaryDAL)
{
    try
    {
        LoadProperty(ClientIdProperty, client.ClientId);
        SetProperty(ClientBeneficiaryIdProperty, await beneficiaryDAL.InsertClientBeneficiary(LoadDTO()));
    }
    catch (Exception ex)
    {
        throw new Exception("Data was not inserted successfully.\n" + ex.Message);
    }
}

When executing the InsertClientBeneficiary method we get the largely disliked Cannot wait on monitors on this runtime error, when looking at the stack trace it is clear that the Update method is called instead of UpdateAsync which uses .Wait() so the error is justified.

at System.Threading.Monitor.ObjWait(Int32 millisecondsTimeout, Object obj)
   at System.Threading.Monitor.Wait(Object obj, Int32 millisecondsTimeout)
   at System.Threading.ManualResetEventSlim.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
   at System.Threading.Tasks.Task.SpinThenBlockingWait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
   at System.Threading.Tasks.Task.InternalWaitCore(Int32 millisecondsTimeout, CancellationToken cancellationToken)
   at System.Threading.Tasks.Task.InternalWait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
   at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
   at System.Threading.Tasks.Task.Wait()
   **at Csla.Server.ChildDataPortal.Update(Object obj, Object[] parameters)**
   at Csla.DataPortal`1[[ClientBeneficiary, Client, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]].UpdateChild(ClientBeneficiary child, Object[] parameters)
   at Csla.BusinessBindingListBase`2[[Client.Beneficiaries.ClientBeneficiaries, Client, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null],[ClientBeneficiary, Client, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]].Child_Update(Object[] parameters)
   at Csla.Reflection.ServiceProviderMethodCaller.CallMethodTryAsync(Object obj, ServiceProviderMethodInfo method, Object[] parameters)'

The question is, why would it call the synchrounous update method?

[clodewyks]

Reverse engineering CallMethodTryAsync I notice the decision which method to call is based off of IsAsyncTask or IsAsyncTaskObject, I then used the same FindDataPortalMethod with the ClientBenficiary object, this method returns that it IsAsyncTask is in fact true, so we would expect the UpdateAsync to be called.

[clodewyks]

Agreed, so if ServiceProviderMethodCaller.CallMethodTryAsync logs that the Update IsAsyncTask, I don't understand why it would be calling Csla.Server.ChildDataPortal.Update(Object obj, Object[] parameters) instead of Csla.Server.ChildDataPortal.UpdateAsync(Object obj, Object[] parameters)

[rockfordlhotka]

Can you isolate the issue into a unit test? Or at least a simple console app that demonstrates the issue?

[clodewyks]

We will attempt to create a minimal reproduction in WASM, as this is where the Platform exception would occur.

[clodewyks]

@rockfordlhotka we have been unable to create a minimal repo, but we have found the issue and have a temporary workaround:

The issue is, as expected, BusinessBindingListBase.Child_Update which calls ChildDataPortal.Update which uses a Wait() .

This is where it gets interesting: Why is this only an issue when using offline? When using a remote DataPortal, the parent call and all subsequent child calls are on the DataPortal, in this case a .NET Core API which allows waiting for monitors, so no issue with .Wait(). When running offline all DataPortal calls are on the client, blazor wasm, which does not support Wait().

In the current CSLA source, there is a BusinessBindingLIstBase.Child_UpdateAsync method: BusinessBindingListBase

In CSLA 6.2.2 there is no such method, our temporary workaround until we can upgrade CSLA is to introduce a base class, inheriting from BusinessBindingListBase, implementing a [ChildUpdate] which is async and calls ChildDataPortal.UpdateAsync