BusinessRuleAsync intermittently loses underlying ApplicationDbContext

[richardbartley]

Describe the bug
Have a complex BusinessEditBase model with a list of child objects. Both have a few async business rules that do database lookups (EF Core). This is a Net6 Web API.

Now and again (yes its annoying - it's intermittent), a BusinessRuleAsync rule will fail to run with Object Disposed error on lines like this;

`
protected class LinesHaveItemsFromRangeRuleAsync : BusinessRuleAsync
{
....
        protected override async Task ExecuteAsync(IRuleContext context)
        {
         ...
     var badLines = await context.ApplicationContext.GetRequiredService<IDataPortalFactory>()
       .GetPortal<CheckLinesInRangeList>()
       .FetchAsync(crit);

Drilling into the error in the CheckLinesInRangeList object, seems the underlying ApplicationDbContext has been disposed.

System.ObjectDisposedException: Cannot access a disposed context instance. A common cause of this error is disposing a context instance that was resolved from dependency injection and then later trying to use the same context instance elsewhere in your application. This may occur if you are calling 'Dispose' on the context instance, or wrapping it in a using statement. If you are using dependency injection, you should let the dependency injection container take care of disposing context instances.
Object name: 'ApplicationDbContext'.

Now I appreciate this may be a more general DotNet Core issue rather than Csla, but would any type of using block cause the issue? I'm DI'ing the context in, and do not dispose of it manually anywhere.

One rule is using a ReadOnlyListBase and has a using (LoadListMode) wrapped around the database call - surely that would not cause the ApplicationDbContext to dispose? When they say a using block they of course mean using (ctx = ApplicatioDbContext) sort of thing.

Version and Platform
CSLA version: 7.0.0
OS: Windows, Linux, iOS, Android, etc.
Platform: ASP.NET Core

Additional context
Running on IIS

[richardbartley]

I do notice some System.ObjectDisposedExceptions in the Output window when debugging in one of the BusinessRuleAsync rules which was

If I switch on the debugger to break on these types of exceptions, I see things like;

Exception thrown: 'System.ObjectDisposedException' in System.Private.CoreLib.dll
IFeatureCollection has been disposed.

or at other times

System.ObjectDisposedException: 'Cannot access a disposed object.
Object name: 'IServiceProvider'.'

I think my real question is this. How do I setup an asp net core app to have scoped dbcontext and scoped repository services, but have the async business rules use their own independent dbcontext thus avoiding disposed object or “this dbcontext cannot share - is not thread safe”.

[ossendorf-at-hoelscher]

Thanks but when you start BusinessRules.CheckRulesAsync() why do you need the validation complete event? The CheckRulesAsync should only return when all async rules are finished. Am I wrong?

[ossendorf-at-hoelscher]

@rockfordlhotka

Still reproducible with the current csla 8 pre-release nuget.

[rockfordlhotka]

Thanks but when you start BusinessRules.CheckRulesAsync() why do you need the validation complete event? The CheckRulesAsync should only return when all async rules are finished. Am I wrong?

You are correct. The event was to support some scenario I've long since forgotten.

[rockfordlhotka]

@ossendorf-at-hoelscher when you say "reproducible", is this something small enough that I can use it for testing/debugging - or that you can?

[ossendorf-at-hoelscher]

I can get it 1x out 5-10 times (depending on the use case).
Maybe I can create an mwe after fixing/avoiding it.

[rockfordlhotka]

Is this with a local or remote data portal?

[ossendorf-at-hoelscher]

It's with a remote data portal hosted on azure.

[richardbartley]

I’m intrigued still as to why IServiceProvider fails occasionally, when in theory the request should still be alive.

Is this article https://learn.microsoft.com/en-us/dotnet/core/compatibility/extensions/6.0/service-provider-disposed saying that it can happen and Net6 fixed a deadlock issue by catching this and throwing an exception that we can now handle?

[ossendorf-at-hoelscher]

Why should the request still be alive?
The flow is:
Request arrives -> Create/Use BOs -> Any BO gets a change with an async rule which takes some time (>1s) -> we/CSLA does not wait for this rule to have finished -> response sent -> request destroyed -> rule comes back and tries to e.g. access an CSLA property which needs an IServiceProvider lookup -> ObjectDisposedException

[rockfordlhotka]

I agree that what we're seeing here is likely caused by #3751