LocalContext is lost inside async DP methods (MVC app)

[j055]

Describe the bug
LocalContext is not available inside DP async Fetch method after being set in an MVC controller action.

It is available in a non-async method call.

Version and Platform
CSLA version: 5.5.1
OS: Windows
Platform: ASP.NET Core, MVC, NETFX 4.8

Code that Fails

    public class HomeController : Controller
    {
        public async Task<ActionResult> Index()
        {
            ApplicationContext.LocalContext["test"] = "test";
            var obj = DataPortal.Fetch<PersonEdit>(123);
            var obj2 = await DataPortal.FetchAsync<PersonEdit>("abc");

            return View();
        }
    }

  [Serializable]
    public class PersonEdit : BusinessBase<PersonEdit>
    {
        public static readonly PropertyInfo<string> NameProperty = RegisterProperty<string>(nameof(Name));
        public string Name
        {
            get => GetProperty(NameProperty);
            set => SetProperty(NameProperty, value);
        }

        public static readonly PropertyInfo<string> ContextProperty = RegisterProperty<string>(nameof(Context));
        public string Context
        {
            get => GetProperty(ContextProperty);
            set => SetProperty(ContextProperty, value);
        }

        public static readonly PropertyInfo<AnotherRoot> AnotherProperty = RegisterProperty<AnotherRoot>(nameof(AnotherRoot));
        public AnotherRoot AnotherRoot
        {
            get => GetProperty(AnotherProperty);
            private set => LoadProperty(AnotherProperty, value);
        }

        [Fetch]
        private void Fetch(int name)
        {
            Context = ApplicationContext.LocalContext["test"].ToString(); // SUCCESS
        }

        [Fetch]
        private async Task FetchAsync(string name)
        {
            Context = ApplicationContext.LocalContext["test"].ToString(); // FAIL
        }
    }

[rockfordlhotka]

LocalContext doesn't flow through the data portal, so there's no expectation that logical client-side LocalContext will exist on the logical server-side. That's the purpose of ClientContext, because it does flow.

Or are you saying that there's an exception when trying to access LocalContext?

I agree that there is different behavior between sync and async, because async is more similar (in practice) to a remote data portal call, while sync is as lightweight as possible, coincidentally running in the same context as the logical client.

[j055]

Way too confusing if the outcome is different though. What if there's a sync dp call inside a async one? The sync one shouldn't know about the parent should it?

[rockfordlhotka]

It has been this way since around 2005 😉

It will change in CSLA 6 though, because the whole way application context is managed stops being "global" and is instead an injected instance of ApplicationContext. That'll allow more consistent behavior, at the cost of some inefficiency for a pure local data portal (which is the sync scenario).

[j055]

Ha ha! I wasn't doing much async programming back in 2005! Not too sure if LocalContext is that useful then? Why would you use it instead of ClientContext?

[rockfordlhotka]

The intent of LocalContext is to provide a way to have global state on the client and different global state on the server, both such that the state is managed for you by CSLA, so it

1. Flows across threads, sync contexts, etc.
2. Is automatically removed from the server when the server call completes

The intent of ClientContext is to provide a way to have global state on the client, with that state flowing to the server with each data portal call, so the server has a copy of the client state.

I agree that the use of LocalContext is quite limited, and in most cases ClientContext is what people would want to use.

[j055]

That's really helpful. Up to now I've always associated LocalContext, incorrectly, with being potentially useful in a local data portal scenario. Perhaps if it had a different name, like ConfinedContext, RestrictedContext, IsolatedContext, SimpleContext, LimitedContext it would be less confusing? But I'm not suggesting it should be changed now. I'll stick with ClientContext in future.