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: https://github.com/dotnet/aspnetcore/issues/38842#issuecomment-986905123

[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

[andrzejczar84]

@TanayParikh Done.

Here is simple Blazor App reproducing problem: https://github.com/andrzejczar84/FileUploadBug.Net6

Screenshot below - the same jpg, the same bytes read, the same freez of app after several seconds

Edit: I have checked also similar code to upload PDF files. Same way file stream read-only part of the file. Put into database incomplete byte array, and it's brokeen after downloading from DB, so the issue is not only about pictures.

[TanayParikh]

Thanks @andrzejczar84, I'm able to repro.

I have checked also similar code to upload PDF files. Same way file stream read-only part of the file.

Would you mind committing this into your github repo (omitting the DB dependency).

Side note, I recommend checking out the new image upload guidance available here to help avoid having to Base64 encode images.

[andrzejczar84]

@TanayParikh repo updated with pdf upload.

I tried to upload 1,8Mb file.

Method passed but uploaded only ~64kb

[huseyin-ezemi]

Hi to all this code worked for me :

        protected virtual async Task GetFile(InputFileChangeEventArgs e)
        {
               if (e.File != null)
                {
                    var buffer = new byte[e.File.Size];
                    var fileContent = new StreamContent(e.File.OpenReadStream(1024 * 1024 * 15));
                    buffer = await fileContent.ReadAsByteArrayAsync();

                    var result = new File
                    {
                        Content = buffer,
                        ContentType = e.File.ContentType
                    };
                 }
        }

[Bobetti]

After upgrading my Blazor Server Side application, I found out that file upload to Azure blob is not working anymore for any file.

For example, if I upload 5MB image file, I get on azure blob a 50MB ruined image file. If I upload a video file 12Mb, I get on azure 120MB ruined file.

Here is my upload code:

 private async Task<UploadResult> UploadFileInChunksAsync(string prefix, IBrowserFile file, CancellationToken cancellationToken)
        {

            var result = new UploadResult()
            {
                FileName = file.Name
            };

            try
            {

                var fullFileName = string.Format("{0}{1}", prefix, file.Name);

                var blockBlobClient = _containerClient.GetBlockBlobClient(fullFileName);

                int blockSize = 1 * 1024 * 1024; //1 MB Block
                int offset = 0;
                int counter = 0;

                List<string> blockIds = new List<string>();

                using (var fs = file.OpenReadStream(_maxAllowedSize))
                {
                    var bytesRemaining = fs.Length;

                    do
                    {
                        var dataToRead = Math.Min(bytesRemaining, blockSize);
                        byte[] data = new byte[dataToRead];
                        var dataRead = await fs.ReadAsync(data, offset, (int)dataToRead);
                        bytesRemaining -= dataRead;
                        if (dataRead > 0)
                        {
                            var blockId = Convert.ToBase64String(Encoding.UTF8.GetBytes(counter.ToString("d6")));
                            await blockBlobClient.StageBlockAsync(blockId, new MemoryStream(data));
                            Console.WriteLine(string.Format("Block {0} uploaded successfully.", counter.ToString("d6")));
                            blockIds.Add(blockId);
                            counter++;

                            cancellationToken.ThrowIfCancellationRequested();
                        }
                    }
                    while (bytesRemaining > 0);

                    // Console.WriteLine("All blocks uploaded. Now committing block list.");

                    await blockBlobClient.CommitBlockListAsync(blockIds);

                    // Console.WriteLine("Blob uploaded successfully!");

                    result.Uploaded = true;
                    result.Uploading = false;
                }
            }

            catch (Exception ex)
            {
                result.Uploaded = false;
                result.ErrorMessage = ex.Message;
            }

            return result;
        }

After digging, I found out that this line: var dataRead = await fs.ReadAsync(data, offset, (int)dataToRead); always reads only 32256 bytes of info

Here are some test results with different solutions: .Net5 and .Net6 - uploading the same file:

correctly working upload in .NET 5 var bytesRemaining = fs.Length => 5317702 dataToRead => 1048576 dataRead => 1048576 bytesRemaining => 4269126 . . .

5 junks in total

=====

Not working .NET 6 results

bytesRemaining => 5317702 dataToRead => 1048576 dataRead => 32256

50 junks in total, ruined file

Any help with what to do next?

[Bobetti]

After some thinking and considering that in .Net 6 ReadAsync function reads the random number of data and not like in .Net 5, specific amount, I rewrote upload function this way:

var blockBlobClient = _containerClient.GetBlockBlobClient(AzurePrefix);

                int blockSize = 1 * 1024 * 1024; //1 MB Block                
                int counter = 0;
                List<string> blockIds = new List<string>();

                using var fs = fileToUpload.BrowserFile.OpenReadStream(_maxAllowedSize);

                var bytesRead = 0;
                var buffer = new byte[blockSize];

                while ((bytesRead = await fs.ReadAsync(buffer)) != 0)
                {
                    using var writeStream = new MemoryStream();
                    await writeStream.WriteAsync(buffer, 0, bytesRead);
                    writeStream.Position = 0;

                    var blockId = Convert.ToBase64String(Encoding.UTF8.GetBytes(counter.ToString("d6")));
                    await blockBlobClient.StageBlockAsync(blockId, writeStream);                  

                    counter++;

                    blockIds.Add(blockId);

                }

                await blockBlobClient.CommitBlockListAsync(blockIds);

Now, seems to me everything works fine. Files uploaded in correct size.

[TanayParikh]

Hi all, I took another look through the repro, and that behavior is by design.

Please note per the Stream.ReadAsync docs:

The result value can be less than the number of bytes allocated in the buffer if that many bytes are not currently available, or it can be 0 (zero) if the end of the stream has been reached.

That's essentially what's happening in this case. When a single call is made to ReadAsync, it only gives you the first (few) chunks that have been sent from JS, you are not guaranteed to receive the full file. Blazor subsequently throws an error as you've only read a part of the stream and the stream subsequently times out.

The way you'd want to achieve this would be by leveraging Stream.CopyToAsync or by using Stream.ReadAsync using smaller chunks until you reach the end of the stream. Note this is in line with our streaming and file upload guidance. Specific examples and sample code are also available in those docs pages.

Note in @huseyin-ezemi's comment above, they used ReadAsByteArrayAsync, that could also work as they're allowing the whole stream to be read. Note this may pose some security & scalability concerns as you're storing the whole stream/file in memory. This approach isn't recommended.

                 var fileContent = new StreamContent(e.File.OpenReadStream(1024 * 1024 * 15));
                 buffer = await fileContent.ReadAsByteArrayAsync();

The above explains the behavior presented within @andrzejczar84's repro app, however in the original issue @Liero mentions running into this with CopyToAsync. This is more concerning, however I've been unable to repro. If @Liero, @angularsen or anyone else has a repro of this issue with CopyToAsync, I'd very much be interested in it. I'm marking this issue as "needs author feedback", it'll get auto-closed after a while if a repro can't be found. Though please feel free to re-open / start a new issue (and link this issue) if you do end up finding a repro with CopyToAsync.

[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.

[TanayParikh]

From @Liero's comment above:

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

I think you're onto something here. The timeout for the stream begins when you call OpenReadStream which calls into the BrowserFileStream which calls into the stream reference, leading to the runtime which in turn kicks of the stream and timeout.

Hence, if you're doing OpenReadStream and then waiting (past the timeout) to actually read from the stream, you'd encounter this error.

[Liero]

@TanayParikh: I've later realized, that the problem only occurred when the app was running in on-premise IIS, which has websockets disabled by default.

So in order to reproduce it:

1. use long polling instead of websockets
2. select larger file to upload (5MB)
3. call IBrowserFile.OpenReadAsync from click or form submit callback one minute later after InputFile.Change callback (see original post)

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[hri123phapale]

@angularsen , I have same issue as you mention above. Do you get the any solution for it ?

Below mention code was perfectly working with .Net5 but recently we have migrated to .Net6 and file uploading stop working with the files having size more that 400-500 KB. Its working fine with small size files. If we uncomment the commented lines(2 lines) from below code , its start working again.

protected async Task OnChangeHandler(InputFileChangeEventArgs args)
     {
         IReadOnlyList<IBrowserFile> files = args.GetMultipleFiles(100);
         List<UploadItem> items = new List<UploadItem>();
         int currentCount = 0;
         foreach (var file in files)
         {
             if (!IsValidFileType(file))
             {
                 continue;
             }
             if (currentCount >= CurrentAllowedAmount)
             {
                 break;
             }
             currentCount++;
             var fileStream = file.OpenReadStream(_maxFileSize * ByteToMByte);
             //byte[] buffer = new byte[file.Size];
             var fileContent = new StreamContent(fileStream);
             //buffer = await fileContent.ReadAsByteArrayAsync();
             items.Add(new UploadItem
             {
                 FileContent = fileStream,
                 Content = fileContent, 
                 File = file,
                 State = UploadState.ToUpload,
                 MaxFileSize = MaxFileSize,
                 IsFileValid = IsFileValid(file)
             });
         }
         await OnChange.InvokeAsync(items);
         Message = GetLatestMessage();
     }

Does anyone have solution for it?

[TanayParikh]

@hri123phapale please see https://github.com/dotnet/aspnetcore/issues/38842#issuecomment-1151415351 above. I believe this is likely the same thing happening here.

[Liero]

@hri123phapale: Also make sure, websockets are enabled, see

[hri123phapale]

@Liero Yes, its connected

[Liero]

hey, I see that you open the stream without reading it:

var fileStream = file.OpenReadStream(_maxFileSize * ByteToMByte);
var fileContent = new StreamContent(fileStream);

and pass it to evencallback:

items.Add(new UploadItem
{
  FileContent = fileStream,
  Content = fileContent, 
  File = file,
}
await OnChange.InvokeAsync(items);

so you attempt to read it later in the event handler probably. This is wrong. You have to read the stream immediately after calling OpenReadStream(), otherwise it can timeout.

[hri123phapale]

@Liero , Same code was perfectly working in .NET5. We have migrated to .NET6. But same code is not working with .NET6.

[Liero]

Same code was perfectly working in .NET5

I'm not saying otherwise. I'm saying you should follow the guidelines.

[Liero]

@TanayParikh: maybe it would be worth updating the blazor upload guideline with https://github.com/dotnet/aspnetcore/issues/38842#issuecomment-1151415351 - the warning about ReadBytes() and about websockets.

BTW, using Long polling, there is probably no way to upload larger file, is it? Seems like a bug to me. I can create new issue specifically for long polling upload

[hrvoje-grabusic]

@Liero Also in those docs Pages/FileUpload2.razor example code causes exactly this issue when uploading more then one file. When uploading two files it doesn't read the stream right away and it freezes.

[Bluejanis]

We are using IIS, but have websockets enabled and still experience this error. It only occurs when uploading 2 or more files simultaneously, which are at least 400kb of size.

3 Files of 200kb => no issue 1 File of 8MB => no issue 2 Files of 400kb => System.TimeoutException: 'Did not receive any data in the allotted time.'

Edit: But I suspect I did not use the stream quick enough, als Liero wrote. OpenReadStream() was called again on the second file before the first stream was even used.

Edit2: Once I changed that, the error disappeared.

[sipi41]

I'm having also this problem... what I did is to read the File Input content using Javascript, in other words have the BLOB data transfered via JS and then it did work but certainly, a random issue with MS inputfile component.

` Stream stream = file.OpenReadStream(maxAllowedSize: 2147483648);

                MemoryStream memoryStream = new MemoryStream();

                await stream.CopyToAsync(memoryStream); //----> PROBLEMATIC LINE`

[BhavanaShrotri]

I am facing the same issue after migrating Dotnet 5 to 6.

Getting this error after selecting a file using InputFile Component.

[oruchreis]

Has any update for this issue? I've tried with many browsers and with or without websocket connected. I've also tried with net 7, it still can't read the stream and throws Did not receive any data in the allotted time. So this error occurs after upgrading to .net 6 and .net 7, and it doesn't occur in .net 5.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. 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.

[TanayParikh]

We've investigated and verified this bug. We're planning on tackling this in the next release.

[qw-34]

We have same issue, but it works on .NET 6 and only broken after migrate to .NET 7.

[haas-daniel]

We had the same issue in .NET 7 and fixed it by setting the SignalR DisableImplicitFromServicesParameters-option to true: https://learn.microsoft.com/en-us/dotnet/api/Microsoft.AspNetCore.SignalR.HubOptions.DisableImplicitFromServicesParameters?view=aspnetcore-7.0&viewFallbackFrom=net-7.0

builder.Services
    .AddServerSideBlazor()
    .AddHubOptions(opt =>
    {
        opt.DisableImplicitFromServicesParameters = true;
    });

Background: SignalR tries to call this method https://github.com/dotnet/aspnetcore/blob/de68feabb4dc84d2d5fbcfd7b3ed0b08f53216fa/src/Components/Server/src/ComponentHub.cs#L225 but fails because of incorrect argument count.

This method is registered in SignalR with 3 parameters instead of 4. That's because we use Autofac as IoC container and Autofac tells SignalR that it can provide a service for the byte[] parameter. https://github.com/dotnet/aspnetcore/blob/971df4cbdc045c879f288b8cdfd726fd4212f882/src/SignalR/server/Core/src/Internal/HubMethodDescriptor.cs#L83

[DavidWaterfield]

@haas-daniel That solution worked for us. Thanks for sharing

[oruchreis]

I'm using DryIoc with builder.Host.UseServiceProviderFactory, and I was faced this issue. After I saw that uninstalling the DryIoc library fixed it, I reported it to the DryIoc repo here: https://github.com/dadhi/DryIoc/issues/547 But I don't know which repo should handle this issue. Should this bug be fixed by DryIoc and other DI libraries like Autofac or should lt be handle here?

[12evenant]

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();
        }
    }

[robi26]

Having exactly the same issue. We are using Lamar. @haas-daniel thanks for the workaround!

[alpisala02]

We have same issue after updating .NET 6 to .NET 7 on InputFile component. Unfortunately the workarounds didnt work for us.