6.1.0 error in biz obj returned by a custom exception using LocalProxy

[swegele]

Blazor Server Side - I think I've found an error that was introduced in 6.1.0 release. Things worked fine in 6. Admittedly this is an edge case and makes sense how it would have snuck through (? perhaps related to #3004 ?).

On login attempt when the user's password is correct BUT EXPIRED, I create a biz object that represents the needed behavior called ForceChangePasswordAtLogin. I return it as a public property on a custom exception LogonFailedExceptionPasswordExpired. I've used this mechanism for many years as a little extra security so that the only way to get one of these special objects is for a user to actually trigger do the good login. The special object has no public create or fetch...the only way to get one is via this exception.

Well the trouble is as of 6.1.0 when I get this object from the exception, all of the properties of any type throw

Message:
"Cannot access a disposed object.\r\nObject name: 'IServiceProvider'."

StackTrace:

"   at Microsoft.Extensions.DependencyInjection.ServiceLookup.ThrowHelper.ThrowObjectDisposedException()\r\n   at 
Microsoft.Extensions.DependencyInjection.ServiceLookup.ServiceProviderEngineScope.GetService(Type serviceType)\r\n   at
Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService(IServiceProvider provider, Type serviceType)\r\n   at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService[T](IServiceProvider provider)\r\n   at Csla.Core.ApplicationContextAccessor.GetContextManager()\r\n   at
 Csla.Core.BusinessBase.VerifyAuthorizationCache()\r\n   at Csla.Core.BusinessBase.CanReadProperty(IPropertyInfo property)\r\n   at
 Csla.Core.BusinessBase.CanReadProperty(IPropertyInfo property, Boolean throwOnFalse)\r\n   at
 Csla.Core.BusinessBase.GetProperty[P](PropertyInfo`1 propertyInfo, NoAccessBehavior noAccess)\r\n   at
..."

Interesting detail that leads me to suspect changes in LocalProxy...my automated tests pass fine when doing this action.
My automated tests run this scenario just fine, but that is because I turn off the use of LocalProxy for automated tests because the added overhead of creating/using/disposing the LocalProxy for a long serial run of many thousands of tests causes a HUGE perf degradation. If I enable the enable the LocalProxy then I see the failure the same as I do in my Blazor app.

?Safe to assume that the old (6.0.0) LocalProxy did the post DataPortal processing so that the returned object has the correct instance of IServiceProvider and the correct ApplicationContext (remember all that fun debugging? to get that working right) ?

I say this is an edge case because it's probably not common to return business objects in an exception...but hey I'm special :-)
Do we think this could be fixed? Do I need to refactor this to not use an exception?

[rockfordlhotka]

We fixed a 6.0 bug in 6.1, where the ApplicationContext referenced by an object graph wasn't being updated as the object graph switched from the temporary scope in LocalProxy back to the caller's scope. This was preventing the use of temporary scope in LocalProxy (which is important), and so I think you are hitting the new feature - which is that LocalProxy now properly does use a temporary scope.

You can disable the use of temporary scope in LocalProxy, that's an option when you configure to use LocalProxy. You lose the ability to leverage scope to automatically manage database connections and other resources, but it would resolve your issue (I think).

I don't believe we walk any exception graph flowing back from LocalProxy to fix up the ApplicationContext, because you are right, it isn't a regular thing for an exception to reference an object graph. I'm not actually sure that'd work across a remote proxy - not something I've ever considered.

[swegele]

OK - happily, I ended up using the same technique as in #3096 so the object is immediately serialized in the custom exception constructor and kept as a byte[]. Then when delivered it is deserialized and delivered to client. So the refactor was pretty simple. Thanks again!