Blazor Server silent connection crash when using InputFile Component

[mhehle]

Is there an existing issue for this?

• [X] I have searched the existing issues

Describe the bug

If you select more than 250 Files in InputFile Component In Blazor Server, the connection will crash silently. The specified InputFile OnChange method will not get called, there is no way to catch or handle the underlying error/exception.

This issue exists in a production environment with no debugger attatched.

Expected Behavior

InputFile OnChange will get called, no connection crash.

Steps To Reproduce

1. Execute dotnet new blazorserver
2. Go to Index page
3. Add following sourcecode

<h3>Upload</h3>
<p>Please select 300 files to upload</p>
<InputFile OnChange="@UploadImages" multiple/>

@code
{
   private const int MaxFiles = 100;

    private void UploadImages(InputFileChangeEventArgs args)
    {
        try
        {
            var files = args.GetMultipleFiles(MaxFiles);
            foreach (var file in files)
            {
                Console.WriteLine(file.Name);
            }
        }
        catch (Exception e)
        {
            Console.WriteLine(e.Message);
        }
    }
}

4. Run project
5. Upload 300 files
6. Connection will crash

Demo repository: https://github.com/mhehle/BlazorServerInputFileComponentIssue

Exceptions (if any)

No response

.NET Version

Version: 6.0.3 Commit: c24d9a9c91

Anything else?

No response

[mhehle]

possible relevant issues:

• https://github.com/dotnet/aspnetcore/issues/26756
• https://github.com/dotnet/aspnetcore/issues/28547

[javiercn]

@mhehle thanks for contacting us.

Can you turn on the logs to debug level and paste what information you see on the console/log output? Could you check on the browser logs to see any message that might be logged out in the client?

[ghost]

Hi @mhehle. We have added the "Needs: Author Feedback" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[mhehle]

@javiercn thanks for your fast response

Client Log

[2022-07-11T12:59:37.855Z] Information: Normalizing '_blazor' to 'https://localhost:7144/_blazor'.
blazor.server.js:1 [2022-07-11T12:59:37.928Z] Information: WebSocket connected to wss://localhost:7144/_blazor?id=mYaN8bMWaa7OAgOXf0CxFg.
blazor.server.js:1 [2022-07-11T13:00:03.303Z] Error: Connection disconnected with error 'Error: Server returned an error on close: Connection closed with an error.'.
  log                   @ blazor.server.js:1
  _stopConnection       @ blazor.server.js:1
  transport.onclose     @ blazor.server.js:1
  _close                @ blazor.server.js:1
  stop                  @ blazor.server.js:1
  _stopInternal         @ blazor.server.js:1
  await in _stopInternal (async)
  stop                  @ blazor.server.js:1
  _processIncomingData  @ blazor.server.js:1
  connection.onreceive  @ blazor.server.js:1
  o.onmessage           @ blazor.server.js:1
blazor.server.js:1 [2022-07-11T13:00:06.305Z] Information: Normalizing '_blazor' to 'https://localhost:7144/_blazor'.
blazor.server.js:1 [2022-07-11T13:00:06.326Z] Information: WebSocket connected to wss://localhost:7144/_blazor?id=J53wv2tQn_B-1-kdPQKQ8w.

On server side there are no logs in the console, even with following log configuration:

  "Logging": {
    "LogLevel": {
      "Default": "Debug",
      "Microsoft.AspNetCore": "Debug"
    }
  }

[javiercn]

@mhehle check appsettings.json because I think those might change the levels. There should be plenty of debug logs if you did this correctly.

I am going to go on a limb and theorize that you are likely hitting the signalr message size level. Very likely you can increase the message size and it will work. Note however there are security implications in doing so https://docs.microsoft.com/en-us/aspnet/core/signalr/security?view=aspnetcore-6.0#buffer-management

[ghost]

Hi @mhehle. We have added the "Needs: Author Feedback" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[mhehle]

@javiercn you were right, the Debug log shows an InvalidDataException with the hint that the maximum message size of 32768B was exceeded.

dbug: Microsoft.AspNetCore.SignalR.HubConnectionHandler[2]
      => SpanId:fbbce1ebdd4cd062, TraceId:f08cc5cb503b0ebd1300a0bea5894b1a, ParentId:0000000000000000 => ConnectionId:0HMJ38F2TNPAN => RequestPath:/_blazor RequestId:0HMJ38F2TNPAN:00000002 => TransportConnectionId:H1LuAuA7tUEWvq5NRo7Dag
      Error when processing requests.
      System.IO.InvalidDataException: The maximum message size of 32768B was exceeded. The message size can be configured in AddHubOptions.
         at Microsoft.AspNetCore.SignalR.HubConnectionHandler`1.DispatchMessagesAsync(HubConnectionContext connection)
         at Microsoft.AspNetCore.SignalR.HubConnectionHandler`1.RunHubAsync(HubConnectionContext connection)

Is there a more reliable way to solve the problem than increasing the message size?

Nevertheless, the hint would be very helpful in the documentation. currently I can't find anything about this.

[javiercn]

Is there a more reliable way to solve the problem than increasing the message size?

Unfortunately, no, it would complicate the InputFile implementation a lot and it would benefit only a small number of users dealing with a very large number of file uploads, which they can already do by increasing the message size, so it is hard for us to justify any investment to lift this limitation.

In your case, I would either increase the message size limit (as long as you don't give it anything extreme, like 1GB, you are likely ok (try with 64Kb for example). However as with any security limit, you need to understand the impact and test accordingly) or limit the number of files to something you are guaranteed to succeed with, like 50, 100 or 150 (not sure where the boundary is).