Blazor Wasm - HttpClient Disposed on DataPortal Fetch - CSLA 6.1

[saulyt]

I am having an issue where my HttpClient is getting disposed the third time I attempt to fetch an item from the remote DataPortal. I have a grid populated with a list of info objects. When a grid row is double clicked I retrieve the edit object for editing. The first 2 times I double click a grid row everything works as expected. For some reason the 3rd time and on I get a System.ObjectDisposedException on the HttpClient when the DataPortal attempts to fetch the object

I am adding the HttpClient in Program.cs as:
builder.Services.AddScoped(sp => new HttpClient { BaseAddress = new Uri(appSettings.AppServerUrl) });
I tried using AddTransient and had the exact same issue.
CSLA is setup as:

builder.Services.AddCsla(options => options
  .AddBlazorWebAssembly()
  .DataPortal(dpo => dpo
    .UseHttpProxy(hpo => hpo
      .DataPortalUrl = $"{appSettings.AppServerUrl}api/dataportal/")));

Injection of portal into Blazor component:
@inject IDataPortal<Complaint> complaintPortal
Code doing the DataPortal fetch:

async Task EditClick(ComplaintInfo complaint)
    {
        _busy = true;
        _complaintToLoad = await complaintPortal.FetchAsync(complaint.ComplaintID);
        _showEditor = true;
        _busy = false;
    }

Error message on 3rd try and on:

Unhandled Exception:        
       System.ObjectDisposedException: Cannot access a disposed object.
       Object name: 'System.Net.Http.HttpClient'.
          at System.Net.Http.HttpClient.CheckDisposed()
          at System.Net.Http.HttpClient.CheckRequestBeforeSend(HttpRequestMessage request)
          at System.Net.Http.HttpClient.SendAsync(HttpRequestMessage request, HttpCompletionOption completionOption, CancellationToken cancellationToken)
          at System.Net.Http.HttpClient.SendAsync(HttpRequestMessage request) 
          at Csla.Channels.Http.HttpProxy.CallViaHttpClient(Byte[] serialized, String operation, String routingToken) 
          at Csla.Channels.Http.HttpProxy.CallDataPortalServer(Byte[] serialized, String operation, String routingToken, Boolean isSync)        
          at Csla.DataPortalClient.DataPortalProxy.Fetch(Type objectType, Object criteria, DataPortalContext context, Boolean isSync)
          at Csla.DataPortal`1.<DoFetchAsync>d__19[[Library.Business.Complaints.Complaint, Library.Business, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null]].MoveNext()        
          at Csla.DataPortal`1.<FetchAsync>d__23[[Library.Business.Complaints.Complaint, Library.Business, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null]].MoveNext()   
          at UI.Blazor.Pages.Complaints.ComplaintDashboard.EditClick(ComplaintInfo complaint) in UI.Blazor\Pages\Complaints\ComplaintDashboard.razor:line 140
          at UI.Blazor.Pages.Complaints.ComplaintDashboard.<BuildRenderTree>b__0_6(ComplaintInfo item) in UI.Blazor\Pages\Complaints\ComplaintDashboard.razor:line 39
          at Microsoft.AspNetCore.Components.ComponentBase.CallStateHasChangedOnAsyncCompletion(Task task)
          at UI.Blazor.Pages.Complaints.ComplaintGrid.<BuildRenderTree>b__0_0(ComplaintInfo complaint) in UI.Blazor\Pages\Complaints\ComplaintGrid.razor:line 15
          at Microsoft.AspNetCore.Components.ComponentBase.CallStateHasChangedOnAsyncCompletion(Task task)
          at UI.Blazor.Shared.ApDataGrid`1.<OnRowClick>d__13[[Library.Business.Complaints.ComplaintInfo, Library.Business, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null]].MoveNext() in UI.Blazor\Shared\ApDataGrid.razor:line 35
          at UI.Blazor.Shared.ApDataGrid`1.<<OnInitialized>b__11_1>d[[Library.Business.Complaints.ComplaintInfo, Library.Business, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null]].MoveNext() in UI.Blazor\Shared\ApDataGrid.razor:line 23

Does anyone have any ideas?

Thanks

[rockfordlhotka]

I don't know. It doesn't happen in the BlazorExample app after numerous data portal operations.

[saulyt]

I also notice that the code in my ClaimsPrincipalFactory gets hit whenever there is a CreateAsync RunLocal. This is reproducible on the CSLA sample Blazor app after I modified it to use Azure AD and a ClaimsPrincipalFactory. Is this to be expected? (Debugging Blazor WASM is proving very trying, as I can't figure out how to step into external class libraries.)

[saulyt]

@rockfordlhotka, After more time spent than I care to admit, I can finally reproduce the issue in the CSLA Blazor Sample App. I modified the app to demonstrate the issue and pushed it here

If you use _serviceProvider.GetService<IDataPortal<T>>()for any type within a ClaimsPrincipalFactory, if you attempt anywhere in the application a DataPortal<T>.CreateAsync() for any type that has the Create method set to RunLocal, the HttpClient will get disposed, and any subsequent call to the server side data portal will fail.

I made the following modification to the sample app:
In BlazorExample.Client I added the nuget packages required for Azure AD authentication and the required script tag in index.html
In program.cs I wired up Azure AD with a ClaimsPrincipalFactory

builder.Services.AddMsalAuthentication(options =>
{
    options.ProviderOptions.Authentication.Authority = "https://login.microsoftonline.com/";
    options.ProviderOptions.Authentication.ClientId = "ClientID";
    options.ProviderOptions.Authentication.ValidateAuthority = false;
    //builder.Configuration.Bind("AzureAd", options.ProviderOptions.Authentication);

}).AddAccountClaimsPrincipalFactory<AppClaimsPrincipalFactory<RemoteUserAccount>>();

I added AppClaimsPrincipalFactory.cs with the CreateUserAsync method:

public async override ValueTask<ClaimsPrincipal> CreateUserAsync(TAccount account, RemoteAuthenticationUserOptions options)
{
    var user = await base.CreateUserAsync(account, options);
    //getting any DataPortal<T> over here will cause the HttpClient to get disposed when
    //a DataPortal<T>.CreateAsync() that is set to RunLocal is used anywhere in the app. See ListPerson.razor for example
    var userPortal = _serviceProvider.GetService<IDataPortal<UserEdit>>();

    if (account != null)
    {
        var identity = user.Identity as ClaimsIdentity;
        //fetch user with userPortal.FetchAsync
        //add claims from fetched user
    }
    return user;
}

I added the UserEdit class to the BlazorExample.Shared project. It is just an Editable CSLA business object with no code. It could have been any BO.

In ListPersons.razor:
I injected @inject Csla.IDataPortal<TestEdit> testEditPortal. The TestEdit BO just has a Create method with the RunLocal attribute, no other code.
I added to the OnParametersSetAsync method:

//testEditPortalCreateAsync() will cause the HttpClient to get disposed which 
//will cause the personListPortal.FetchAsync() to fail
var t = await testEditPortal.CreateAsync();

My question started by stating that the HttpClient would be disposed the second time I tried to Fetch an object from the server. This was because I am using a CreateAsync after I do the Fetch. The first time I was able to Fetch the object without an issue, but once I called CreateAsync the HttpClient got disposed. On attempting to Fetch the second time I get the ObjectDisposedException.

Any idea why this would happen?

Thank you.

[rockfordlhotka]

fyi, I'm following your comments, but am on a trip and haven't had time to try anything. I'm flying back to the US today, so should have time to try what you are describing early next week. Thank you for all your help to create a repro!

[rockfordlhotka]

I suspect that the problem is not with identity, but with RunLocal. You are mixing the use of the local data portal and remote data portal. That should be fine, but I suspect that is where the problem is happening.

[saulyt]

Thanks for getting back to me, and safe travels.

I don't think the problem is with identity either. The only way I can reproduce it though, is by instantiating a DataPortal in the ClaimsPrincipalFactory. If I inject a service provider in to the ListPersons component, and instantiate the DataPortal before calling CreateAsync, the issue does not occur. I suspect if has something to do with the way the ClaimsPrincipalFactory middleware is working, and probably would happen if I used some other middleware as well. I am just not familiar with any others in Blazor Wasm to give it a try.

I'll be out next week until Wednesday. Have a great weekend and thanks again.

[saulyt]

If I change the registration of the HttpClient to AddSingleton instead of AddScoped, I do not have this issue. I do not understand why this would make a difference as the documentation states "Blazor WebAssembly apps don't currently have a concept of DI scopes. Scoped-registered services behave like Singleton services." I have no idea what the ramification will be in making this change.

[ajohnstone-ks]

I think you might be fine; IIRC you're only supposed to create and re-use a single instance of HttpClient anyway.

https://stackoverflow.com/a/15708633

[saulyt]

I'm afraid I am missing something more basic here, and if I just make the HttpClient a Singleton I am only kicking the can down the road. My suspicion is this is related to the question I asked here regarding a circular dependency in the ClaimsPrincipalFactory. I actually hadn't noticed Rocky's update in the answer until now. I assumed that since I wasn't getting any circular dependency errors all was good. @rockfordlhotka would the circular dependency explain why every time I use CreateAsync with RunLocal I wind up back in the CreateUserAsync method of the ClaimsPrincipalFactory? Should CreateLocal be causing that? If it should, I still don't understand enough about DI to know whether that would/should mess with the scopes and the HttpClient getting disposed. It would mean though, that my using CreateLocal would be of no benefit. I am using it to avoid a trip to the remote data portal when creating a BO. If I am going to wind up there anyway in order to load the users claims, I wouldn't really be saving anything.

[ajohnstone-ks]

I'm not sure what relation this issue may have with the other one you linked. Although it says scoped instances should act as singletons, clearly something is disposing the scope at some point before you're done with it, or the container wouldn't be giving someone a disposed HttpClient.

At any rate making HttpClient a singleton should be the right thing to do, regardless of anything else that is going on.

[rockfordlhotka]

@saulyt - it is important to distinguish between the aspnetcore Blazor docs that are trying to compare and contrast Blazor server with Blazor wasm with Razor Pages, and the actual behavior of DI scopes in code that uses them.

It is true that Blazor wasm doesn't create DI scopes, where Blazor server creates a scope per-user. I think that's what the docs are getting at.

HOWEVER, if your code (or a framework you use, like CSLA) creates DI scopes, then all the normal DI scope rules apply in Blazor wasm just like in all other runtime environments!

If you register a service as scoped, you will get an instance in any scope that uses that service. CSLA does create a scope when you use LocalProxy (including the use of RunLocal).

As a result, any services that have been registered as scoped will get a new instance created within any local data portal call. That's just normal DI, having nothing to do with Blazor wasm at all.

I think (personally) that the Blazor wasm docs are misleading, because you could read them and think that normal DI rules don't apply - when those rules do apply.

[saulyt]

I understand what you're saying regarding DI scopes in the Blazor wasm framework itself vs other frameworks/your own code. Did you get a chance to look at the comment I left earlier today?

I'm afraid I am missing something more basic here, and if I just make the HttpClient a Singleton I am only kicking the can down the road. My suspicion is this is related to the question I asked here regarding a circular dependency in the ClaimsPrincipalFactory. I actually hadn't noticed Rocky's update in the answer until now. I assumed that since I wasn't getting any circular dependency errors all was good. @rockfordlhotka would the circular dependency explain why every time I use CreateAsync with RunLocal I wind up back in the CreateUserAsync method of the ClaimsPrincipalFactory? Should CreateLocal be causing that? If it should, I still don't understand enough about DI to know whether that would/should mess with the scopes and the HttpClient getting disposed. It would mean though, that my using CreateLocal would be of no benefit. I am using it to avoid a trip to the remote data portal when creating a BO. If I am going to wind up there anyway in order to load the users claims, I wouldn't really be saving anything.

Do you think this can be the source of the issue somewhow?

[saulyt]

@rockfordlhotka I think I found what's causing the HttpClient to get disposed. The _httpClient in HttpProxy is declared as static. The LocalProxy calls DisposeScope at the end of the Create method. This is disposing the static _httpClient in HttpProxy. (I have yet to figured out why the LocalProxy _scope only has a reference to the HttpClient if I call _serviceProvider.GetService<IDataPortal<UserEdit>>() in ClaimsPrinipalFactory and not in ListPersons.razor.) Figured it out. See next comment.

[saulyt]

This issue occurs when any code that runs between when the LocalProxy gets created and disposed, instantiates any DataPortal object. When the DataPortal gets instantiates it will create an HttpProxy which has an HttpClient injected into its constructor. The constructor has a _httpClient = httpClient; statement that sets the static _httpClient variable to the new httpClient passed in. When the LocalProxy gets disposed at the end of the Create method, it will dispose of that very same HttpClient that the static _httpClient variable in HttpProxy is now pointing to.

Ultimately, as Rocky assumed, this has nothing to do with the ClaimsPrincipalFactory. It just so happens that when using a ClaimsPrincipalFactory, its CreateUserAsync is going to get called whenever a LocalProxy is created (presumably to setup the user in the LocalProxy's context.) Creating an IDataPortal within that method causes it to get added to the LocalProxy's scope and ultimately dispose the HttpClient. I can now re-create the issue without the ClaimsPrincipalFactory, by just injecting an IDataPortal to any businsess object's create method that is set RunLocal.

I have updated my sample repo that demonstrates this issue accordingly. I removed the AddMsalAuthentication with the AppClaimsPrincipalFactory from program.cs, and just injected an IDataPortal to the TestEdit object's Create method. Creating a TestEdit object prior to calling any other server side dataportal operation, will cause the operation to fail, because the static _httpClient in HttpProxy is now disposed. This is demonstrated in PersonList.razor where the personListPortal.FetchAsync() fails because it comes after testEditPortal.CreateAsync().

Can this be fixed simply by making the _httpClient in HttpProxy non static, or is it intentionally static and changing it will cause other issues?

[saulyt]

I can confirm that is still does not work. @rockfordlhotka I don't think the change made it in to the new 6.2.1 nuget package. I decompiled and it still shows the _httpClient as static.

[rockfordlhotka]

Oh no! This is very sad! I'll try to figure out what happened.

[rockfordlhotka]

@saulyt @clodewyks I just pushed 6.2.2 to nuget. It should be the right code, as I:

1. Completely blanked the bin output directory before doing a build
2. Updated the version numbers, and made sure the output directory got the new 6.2.2 assemblies
3. Built the nuget packages from the newly created bin output directory

[saulyt]

Works! Thank you!

[clodewyks]

@rockfordlhotka thank you, upgraded to 6.2.2 in the sample repo and we have success!