FileUpload: Did not receive any data in the allotted time.

[Liero]

Describe the bug

Not sure if this is a bug but I haven't found any documentation either.

IBrowserFile.ReportFile!.OpenReadStream(maxFileSize).CopyToAsync(fileStream); sometimes throws

System.TimeoutException: Did not receive any data in the allotted time.

To Reproduce

I haven't found a reliable way to reproduce the issue, since it happens only sometimes and have no idea what is causing it.

Here is the code:

IBrowserFile _selectedFile;

void OnSelectedFile(InputFileChangeEventArgs args)
{
    _selectedFile = args.File;
}

private async Task UploadMethod()
{
    string basePath = @"\\fileshare\folder";
    string relativePath = @"{MyFolder\DateTime.Now:dd.MM.yyyy}.pdf";
    string fullPath = Path.Combine(basePath, relativePath);
    using FileStream fs = new FileStream(fullPath, FileMode.Create);

    const long maxFileSize = 5000000; // 5 MB
    if (_selectedFile.Size > maxFileSize)
    {
        Toasts.ShowError("Chyba pri ukladaní. Súbor OTDR má viac ako 5 MB.", "OTDR Report");
    }
    else
    {
        _selectedFile.OpenReadStream(maxFileSize).CopyToAsync(fs);
    }
}

Exceptions (if any)

System.TimeoutException: Did not receive any data in the allotted time.

``` [ { "method":"System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw", "level":0, "line":0, "assembly":"System.Private.CoreLib, Version=6.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e" }, { "method":"System.IO.Pipelines.Pipe.GetReadResult", "level":1, "line":0, "assembly":"System.IO.Pipelines, Version=6.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" }, { "method":"System.IO.Pipelines.Pipe.GetReadAsyncResult", "level":2, "line":0, "assembly":"System.IO.Pipelines, Version=6.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" }, { "method":"System.IO.Pipelines.PipeReaderStream+d__30.MoveNext", "level":3, "line":0, "assembly":"System.IO.Pipelines, Version=6.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" }, { "method":"System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw", "level":4, "line":0, "assembly":"System.Private.CoreLib, Version=6.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e" }, { "method":"System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess", "level":5, "line":0, "assembly":"System.Private.CoreLib, Version=6.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e" }, { "method":"System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification", "level":6, "line":0, "assembly":"System.Private.CoreLib, Version=6.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e" }, { "method":"Microsoft.AspNetCore.Components.Server.Circuits.RemoteJSDataStream+d__36.MoveNext", "level":7, "line":0, "assembly":"Microsoft.AspNetCore.Components.Server, Version=6.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60" }, { "method":"System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw", "level":8, "line":0, "assembly":"System.Private.CoreLib, Version=6.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e" }, { "method":"System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess", "level":9, "line":0, "assembly":"System.Private.CoreLib, Version=6.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e" }, { "method":"System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification", "level":10, "line":0, "assembly":"System.Private.CoreLib, Version=6.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e" }, { "method":"Microsoft.AspNetCore.Components.Forms.BrowserFileStream+d__30.MoveNext", "level":11, "line":0, "assembly":"Microsoft.AspNetCore.Components.Web, Version=6.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60" }, { "method":"System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw", "level":12, "line":0, "assembly":"System.Private.CoreLib, Version=6.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e" }, { "method":"System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess", "level":13, "line":0, "assembly":"System.Private.CoreLib, Version=6.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e" }, { "method":"System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification", "level":14, "line":0, "assembly":"System.Private.CoreLib, Version=6.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e" }, { "method":"Microsoft.AspNetCore.Components.Forms.BrowserFileStream+d__28.MoveNext", "level":15, "line":0, "assembly":"Microsoft.AspNetCore.Components.Web, Version=6.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60" }, { "method":"System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw", "level":16, "line":0, "assembly":"System.Private.CoreLib, Version=6.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e" }, { "method":"System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess", "level":17, "line":0, "assembly":"System.Private.CoreLib, Version=6.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e" }, { "method":"System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification", "level":18, "line":0, "assembly":"System.Private.CoreLib, Version=6.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e" }, { "method":"System.IO.Stream+<g__Core|29_0>d.MoveNext", "level":19, "line":0, "assembly":"System.Private.CoreLib, Version=6.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e" }, { "method":"System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw", "level":20, "line":0, "assembly":"System.Private.CoreLib, Version=6.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e" }, { "method":"System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess", "level":21, "line":0, "assembly":"System.Private.CoreLib, Version=6.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e" }, { "method":"System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification", "level":22, "line":0, "assembly":"System.Private.CoreLib, Version=6.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e" }, { "method":"MyApp.Pages.MyPage+d__54.MoveNext", "level":23, "line":348, "assembly":"MyApp, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null", "fileName":"D:\\a\\1\\s\\src\\app\\Pages\\MyPage.razor.cs" } ] ```

Further technical details

• ASP.NET Core version: 6
• Include the output of dotnet --info:

dotnet --info Output

.NET SDK (reflecting any global.json):
 Version:   6.0.100
 Commit:    9e8b04bbff

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.22000
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\6.0.100\

Host (useful for support):
  Version: 6.0.0
  Commit:  4822e3c3aa

[TanayParikh]

This exception is raised in Blazor Server (here) when the client fails to send any data chunks within the stream for the SignalR JSInteropDefaultCallTimeout.

Are you seeing the client send the stream data chunks within the Developer Tools > Network tab in the browser? Are you behind a VPN or proxy which may be restricting certain packets? If you can provide a public GitHub minimal repro application, it'll allow us to diagnose the issue further.

[ghost]

Hi @Liero. 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.

[ghost]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. If it is closed, feel free to comment when you are able to provide the additional information and we will re-investigate.

See our Issue Management Policies for more information.

[Jesus-QC]

Im having the same issue when I upload big files to the server, it does not happen with small ones.

[TanayParikh]

Im having the same issue when I upload big files to the server, it does not happen with small ones.

This exception is raised in Blazor Server (here) when the client fails to send any data chunks within the stream for the SignalR JSInteropDefaultCallTimeout.

Are you seeing the client send the stream data chunks within the Developer Tools > Network tab in the browser? Are you behind a VPN or proxy which may be restricting certain packets? If you can provide a public GitHub minimal repro application, it'll allow us to diagnose the issue further.

[Jesus-QC]

I just found out this:

Let me try to fix that and i will send here the details.

[Jesus-QC]

Not happening anymore as far as I see!

[angularsen]

I don't have a repro, but we faced the same problem after upgrading Blazor server-side app from .NET5 to .NET6.

We could read the stream immediately after calling OpenReadStream(), but it hung when reading the stream at a later time in the Save button click event handler.

Tried

• Specify max file size argument, or use the default (500kB).
• Calling InvokeAsync to ensure reading the stream on the main thread.
• Different file sizes, ~40 kB was consistently successful while 70+ kB was not.

Workaround

Read and buffer the entire stream in <InputFile OnChange="@LoadFiles" /> event handler, immediately after calling OpenReadStream(). Then we reused that buffer in the Save button click event handler.

We lose the benefit of streaming, but in our use case these were small files and an internal tool, so it was acceptable.

Notes

One interesting symptom was that all button click event handlers stopped responding once this hang occurred, and even a page reload did not fix it. We had to restart the Blazor server to fix it. This page required being logged in, so it might be that this particular circuit had a deadlock of some sort. I really don't understand what was going on.

[TanayParikh]

@angularsen can you confirm if you're on Websockets (not long polling). You should see a warning message like this if you're using long polling.

Also, could you please follow the debug steps/question in my original post: #38842 (comment)

[angularsen]

@TanayParikh Yes, we use websockets.

[2022-01-20T07:46:19.250Z] Information: Normalizing '_blazor' to 'https://xxx/_blazor'. blazor.server.js:1 
[2022-01-20T07:46:19.422Z] Information: WebSocket connected to wss://xxx/_blazor?id=xxx

Are you seeing the client send the stream data chunks within the Developer Tools > Network tab in the browser?

Yes, binary messages are listed on the _blazor blocked request in Chrome dev tools while using the app.

If I select a 40 kB file, I see its binary message listed. I can then click upload and it succeeds.

If I select 80 kB file, I see 3 chunked messages of ~32 kB with its contents. However, the UI now hangs and nothing happens and no additional binary messages are logged when I click the upload button, until it times out and crashes the app after 30 seconds.

In my debugging, it seems reading from the file stream is the root cause. At this point, the blazor app has crashed and is no longer responding.

Are you behind a VPN or proxy which may be restricting certain packets?

No.

If you can provide a public GitHub minimal repro application, it'll allow us to diagnose the issue further.

I will try to find the time, but I can't promise anything.

[TanayParikh]

Thanks @angularsen, that's some great data. Is this a flaky issue, or is it 100% reproducible within your current application? If you haven't already, can you please increase your log levels to Debug/Verbose to ensure we can capture the most data. Setting DetailedErrors: true (per the console log message in your screenshot) may also be helpful to capture the SignalR logs.

If you can provide a public GitHub minimal repro application, it'll allow us to diagnose the issue further.
I will try to find the time, but I can't promise anything.

Thanks, this'll be optimal and ensure I'm able to appropriately investigate this issue.

I'm re-opening this issue ticket.

[angularsen]

It is 100% consistent in our app. Thanks for reopening.

[Liero]

@TanayParikh : I confirm that the symptoms described by @angularsen the same as we experienced. In my original post, the stream is opened fo reading in button click event callback, however I was not able to reproduce it. just found the exception in logs.

I suspect that the key is the delay between Selecting the file and reading the stream

[ghost]

Thanks for contacting us.
We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. Because it's not immediately obvious that this is a bug in our framework, we would like to keep this around to collect more feedback, which can later help us determine the impact of it. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[andrzejczar84]

Hello, same issue here.
Blazor server side. Working well at .Net5, failing on OpenReadStream().ReadAsync() at .Net6.
We use this to upload *.jpg file to sql database.

Method launched as input file change for simple dialog.

        public int readbytes;
        protected async Task OnInputFileChange(InputFileChangeEventArgs e)
        {

            var format = "image/png";

            var imageFile = e.File;
            var resizedImageFile = await imageFile.RequestImageFileAsync(format,
                    400, 200);
            var buffer = new byte[resizedImageFile.Size];
            readbytes = await resizedImageFile.OpenReadStream().ReadAsync(buffer);
            imageDataUrl =
                $"data:{format};base64,{Convert.ToBase64String(buffer)}";

            ImgUploaded = buffer;

        }

In general byte array size is equal to file size. The problem begins in this line

readbytes = await resizedImageFile.OpenReadStream().ReadAsync(buffer);

it reads only part of the buffer, displays part of the picture, then after several seconds throw error

What I investigated checking variable readbytes, it is always the same quantity for the same file.
For example for this picture:

It reads all the time 32256 bytes. Checked on MS Edge and Chrome. The same 32256bytes, so it seams to be not a connection problem.

What is more we have this problem on built soultion already deployed at the Windows Server, and on our VS2022 solutions in debug mode, and at all places in solution where we upload file stream this way. Seams not to be a problem of single machine configuration.

[TanayParikh]

Thanks for the details @andrzejczar84. Would you be able to put together a minimal, public, GitHub repo that reproduces the issue so I may take a look. Also could you provide the image at an external host (GitHub compresses the image pasted into md I believe).

[andrzejczar84]

@TanayParikh here is the picture: https://imgur.com/a/q8L0jwj

I'll try to reproduce the problem at the new minimal repo as fas as it's possible

[erosnemesis]

await stream.ReadAsync(fileBytes);

Hi All, In my case I was able to solve this by closing the stream.

    private async Task<bool> Upload(IBrowserFile file)
    {
        var fileBytes = new byte[file.Size];
        var stream = file.OpenReadStream();
        try
        {
            await stream.ReadAsync(fileBytes);
            //do something
            return true;
        }
        catch (Exception ex)
        {
            //do something
            return false;
        }
        finally
        {
            stream.Close();
        }
    }

This worked for me. Thanks @12evenant

Can confirm that closing the steam solves the issue.

[umartechboy]

I can confirm this too. Closing the stream solves a similar issue in my project too.

Scenario:
MudBlazor installed
FileChanged is called by MudBlazor file selector which is placed inside a MudDialog, reading the stream into buffer works. The rest of the process triggers too, around 3-4 seconds later, the UI Updates from the code become unresponsive. 20-30 seconds later, Timeout exception is thrown.

It was so frustrating to find the root cause because all my tests indicated problems with MudBlazor MudDialog or the CPU intensive work I was doing on the loaded data (WhisperNet. I had to change the library from Whisper.net to WhisperNet, now I feel sorry for blaming Whisper.net)

Resolve
Close the IBrowserFile stream right after read is finished!! A dumb thing to forget, I'd say. Only a desktop app developer can make the mistake.

[DontEatRice]

Any news on this? Still happening when we try to upload multiple files. We do not use AutoFac.
Scenario: server-side Blazor tries to upload more than one file to an external service using HttpClient (RestSharp as wrapper) using streams. When there is more than one file System.TimeoutException: Did not receive any data in the allotted time. is thrown. Closing streams is pointless when they are being read in parallel

[TheAnachronism]

I run into the same issue when doing things parallel.
Although it doesn't actually happen all the time. I haven't been able to figure out which conditions actually cause the exception to happen, which makes it all the more difficult trying to find it.
And like @DontEatRice has mentioned, closing the streams doesn't make a difference, as nothing is received in the first place.

[MackinnonBuck]

Any news on this? Still happening when we try to upload multiple files. We do not use AutoFac. Scenario: server-side Blazor tries to upload more than one file to an external service using HttpClient (RestSharp as wrapper) using streams. When there is more than one file System.TimeoutException: Did not receive any data in the allotted time. is thrown. Closing streams is pointless when they are being read in parallel

@DontEatRice, would you be able to provide us with a repro that demonstrates the bug? The repro we've seen so far wasn't reading the stream to completion (see #38842 (comment)), and others using Autofac mentioned that #38842 (comment) resolved the issue for them.

A repro that demonstrates a framework bug would be very valuable, so if you (or someone else) can provide a minimal repro that doesn't use third-party dependencies and is hosted as a public GitHub repository, that would be much appreciated. Thanks!

[DontEatRice]

@MackinnonBuck

I have created the repo that demonstrates this bug: https://github.com/DontEatRice/BlazorFileUploadIssue
This repo has no third-party dependencies. I have also included a simple api service that saves files to disk.

First run the Web Api in the Api folder.

Go to the BlazorApp folder and run it too. On the left panel you will see the Upload Files tab. You will find sample files in the BlazorApp/Data folder. They have been created using the fsutil command. Select all of them to see the bug. Of course you can use your own files, but the requirement is that they must be at least 2MB each (approximately).

After trying to upload them, Blazor will throw an exception after some time.
You can upload any single file and it will work.

In net7.0 the exception stack trace was longer, something happened, and in net8.0 it is quite short.

Please message me if you have any questions.

[MackinnonBuck]

Thank you for the repro, @DontEatRice! It looks like this is exactly the same issue as #47301, and you can see a detailed explanation here that shows what's going on.

The code in your repro can be modified slightly to make this work:

+var memoryStream = new MemoryStream();
+var browserFileStream = file.OpenReadStream(maxAllowedSize: 15_000_000);
+await browserFileStream.CopyToAsync(memoryStream);
+memoryStream.Position = 0;

-var fileContent = new StreamContent(file.OpenReadStream(long.MaxValue));
+var fileContent = new StreamContent(memoryStream);
fileContent.Headers.ContentType = new MediaTypeHeaderValue(file.ContentType);
fileContent.Headers.ContentDisposition = new ContentDispositionHeaderValue("form-data") { Name = "\"Files\"", FileName = $"\"{file.Name}\"" };

content.Add(fileContent);

---

Within this single GitHub issue, we've seen multiple causes of this exception:

• The app failing to read the stream to completion after calling IBrowserFile.OpenReadStream (not a framework bug)
• Autofac injecting a byte[] argument for a hub method parameter (workaround here)
• A deadlock caused by opening multiple IBrowserFiles for reading at the same time, but consuming them sequentially (framework bug, tracked by Multiple files upload hangs the process in a blazor server app #47301).

So, it's not clear to me whether this issue tracks a unique framework bug. There's a lot of community activity here, but the root cause of the problem seems to vary widely. This probably indicates we should update our documentation to help developers diagnose this issue better.

@guardrex, would you be able to add a section to the file upload docs that explain some of the common causes of this exception?

Also, it looks like the sample in this section might be susceptible to this problem. If that's the case, could we update that sample to take an approach similar to what I wrote above (in the diff)? Thanks!

[guardrex]

@MackinnonBuck ... This one came in, too, which I was waiting to discuss around 🦃 Day. I'll mention this issue to that dev.

dotnet/AspNetCore.Docs#33272

[TheAnachronism]

I have a question about the code example. The documentation mentions that files shouldn't be copied in to a MemoryStream, but should be directly used for whatever happens to them next. (https://learn.microsoft.com/en-gb/aspnet/core/blazor/file-uploads?view=aspnetcore-8.0#file-uploads)

I've done this for my implementation and passed the stream from OpenReadStream to the PutAsync method of a MinioClient for an S3 upload.

[MackinnonBuck]

The documentation mentions that files shouldn't be copied in to a MemoryStream, but should be directly used for whatever happens to them next.

That's true in most cases, but in the repro provided by @DontEatRice, the reading of each stream is controlled by the implementation of MultipartContent, which only consumes each stream just before the request gets made. To avoid the deadlock, each stream needs to be completely consumed before the next call to IBrowserFile.OpenReadStream(). If you want to avoid reading the entire stream into memory, you could limit each request to only transmitting a single file. If you do decide to read into a MemoryStream, ensure that you provide an appropriate maxAllowedSize argument in the call to IBrowserFile.OpenReadStream().

Note that this workaround won't be required:

• If using WebAssembly interactivity, or
• When limiting uploads to one file at a time, or
• After Multiple files upload hangs the process in a blazor server app #47301 gets fixed

[TheAnachronism]

Ah, thank you. Guess I'll change this until that issue is resolved.

[MackinnonBuck]

I'm going to close this out now:

• We've updated our guidance in the docs to account for various possible causes of this exception that aren't framework bugs
• The remaining framework bug is being tracked by Multiple files upload hangs the process in a blazor server app #47301

If others are experiencing this issue and the root cause is not one of those listed in this comment, please open a new issue with detailed reproduction steps and a minimal project that can be used to reproduce the issue (hosted as a public GitHub repository, not a zip file). Thanks!

[Wolfware2023]

Has anyone been able to reproduce this in a BUnit test?
I tried to reproduce the error in a test, but even when it takes forever (>60 seconds) the process does not get timed out.