How to keep async business rules firing on the same thread? IsAsync = false?

[richardbartley]

Describe the bug
Running an ASPNet Core API and trying to keep the EFCore DbContext Scoped rather than Transient.
The initial problem is when async business rules fire, the DbContext errors...

Csla.DataPortalException: 'DataPortal.Fetch failed (A second operation was started on this context instance before a previous operation completed. This is usually caused by different threads concurrently using the same instance of DbContext.

I'm awaiting all async calls, and setting IsAsync = false on the business rules but it still runs the rules on another thread, which EFCore DbContext does not support.

Blows up when the business rule makes the database call via another object.

Example

protected override async Task ExecuteAsync(IRuleContext context)
{
...
  var factories = await context.ApplicationContext.GetRequiredService<IDataPortalFactory>()
    .GetPortal<SupplierFactoryList>()
    .FetchAsync(crit);

Version and Platform
CSLA version: 7.x
OS: Windows
Platform: IIS, ASP.NET Core

    public SetSupplierFactoryIdRule(
        IPropertyInfo SupplierFactoryIdPropertyInfo,
        IPropertyInfo SupplierIdPropertyInfo,
        IPropertyInfo PurchaseOrderTypeIdPropertyInfo)
        : base(SupplierFactoryIdPropertyInfo)
    {
        IsAsync = false;`

[richardbartley]

Mmmm...if I wrap my async businessrules that do database calls on the dbContext in a new scope, that forces a new DbContext I think, and for the most part works around my issue.

using (var scope = context.ApplicationContext.GetRequiredService().CreateScope())

Is that a solution or am I missing a simpler trick here?

[rockfordlhotka]

I believe the data portal in CSLA 7 creates a new DI scope for each root call that uses LocalProxy.

In other words, LocalProxy creates a DI scope for each logical server operation.

A rule typically uses a root operation, and so should get its own DI scope.

@richardbartley are you using CSLA 7? and is your data portal local or remote?

[richardbartley]

@rockfordlhotka Local data portal, unless I've configured it incorrectly.

builder.Services.AddCsla(o =>
{
    o.AddAspNetCore();
    o.DataPortal(dp =>
    {
        dp.AuthenticationType("Csla");
        dp.EnableSecurityPrincipalFlowFromClient();
        dp.UseLocalProxy();
    });
});

[StefanOssendorf]

Mmmm...if I wrap my async businessrules that do database calls on the dbContext in a new scope, that forces a new DbContext I think, and for the most part works around my issue.

using (var scope = context.ApplicationContext.GetRequiredService().CreateScope())

Is that a solution or am I missing a simpler trick here?

You have to be aware that each new scope get's also new scoped objects of other types when resolved within that scope.
Your "problem" is: Async rules are executed in parallel. Hence the exception from the DbContext you get.
One way to solve is to create new scopes (with it's DI drawbacks) or you could check the DbContextFactory stuff (see here even though the example is Blazor it should be usable for other scenarios, too).