aspnetcore
aspnetcore copied to clipboard
dotnet
FileUpload: Did not receive any data in the allotted time.
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+
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.
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.
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.
Im having the same issue when I upload big files to the server, it does not happen with small ones.
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.
I just found out this:
Let me try to fix that and i will send here the details.
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
InvokeAsyncto 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.
@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
@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.
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.
@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
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.
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.
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).
@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
@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.
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.
@TanayParikh repo updated with pdf upload.
I tried to upload 1,8Mb file.
Method passed but uploaded only ~64kb
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
};
}
}
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?
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.
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.
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.
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.
@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:
- use long polling instead of websockets
- select larger file to upload (5MB)
- call
IBrowserFile.OpenReadAsyncfrom click or form submit callback one minute later afterInputFile.Changecallback (see original post)
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.
@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?
@hri123phapale please see https://github.com/dotnet/aspnetcore/issues/38842#issuecomment-1151415351 above. I believe this is likely the same thing happening here.