file upload failed randomly

That error in your screenshot would occur when attempting to view a .pdf file with a size of 0 bytes, since there's no file content to view. That being the case, you'll need to investigate why the file was uploaded without content.

I tested this out myself and haven't been able to reproduce an issue of unexpected 0 byte file uploads, and I don't see other reports of any issues like this, so it sounds like it's specific to your particular environment/scenario. That being the case, you'll need to troubleshoot the uploads locally.

Hi Greg,

We tried reproduce this issue locally, but it can't reproduced. It was reproduced occasionally for us,

And further, we have attached the issue screenshot(Previously reproduced one),

Please check the issue from your end, with the attached screenshot.

Thanks,
Mohamed Aslam

Thanks for following up. It sounds like the issue is sometimes occurring when you use 'new StreamContent(fileStream)', but it's not clear from just this code what the issue may be, so I recommend troubleshooting that particular code path. For instance, you may want to reproduce the issue and inspect what is happening when the issues occurs; you can use a debugger to inspect the state of your code and see if/when and why that data may not be getting populated.

If you've inspected this though and are sure the data is always getting populated in the request body when you see a 0 byte file result, please share some verbose network logging showing that so we can look into it. Thanks!

Hi Greg,

Thanks for your update.

I already pointed out that the issue was reproduced occasionally for me, and i dont know the exact reason of it.

Further, one of the user in our organization faced this issue frequently.

Please find the below code, that we have used to upload document to Dropbox:

// Create the file metadata
var fileMetadata = new
{
	autorename = true,
	mode = "add",
	mute = false,
	path = $"{pathDisplay}/{fileName}.pdf",
};

// Define the API endpoint and request headers
string url = "https://content.dropboxapi.com/2/files/upload";
var requestObj = new HttpRequestMessage(HttpMethod.Post, url);
requestObj.Headers.Authorization = new AuthenticationHeaderValue(Bearer, accessToken);
requestObj.Headers.Add("Dropbox-API-Arg", JsonConvert.SerializeObject(fileMetadata));

// Use the provided fileStream if it is not null, otherwise use fileContent
if (fileStream != null)
{
	requestObj.Content = new StreamContent(fileStream);
}
else
{
	requestObj.Content = new ByteArrayContent(fileContent);
}

requestObj.Content.Headers.ContentType = new MediaTypeHeaderValue("application/octet-stream");

// Send the request and get the response
var responseObj = await this.httpClient.SendAsync(requestObj).ConfigureAwait(false);

We have passing Stream and ByteArray Content like below,

// Use the provided fileStream if it is not null, otherwise use fileContent
if (fileStream != null)
{
	requestObj.Content = new StreamContent(fileStream);
}
else
{
	requestObj.Content = new ByteArrayContent(fileContent);
}

There is no issue while uploading the document using ByteArrayContent, they only issue occurs occasionally was using the StreamContent.


In our organization, we have been using Google drive, and OneDrive too, they are working fine without any issue. Same kind of parameters and request are send for all drives.

The /2/files/upload Dropbox API endpoint is a "content-upload" style endpoint, so the client needs to send the file data it wants to upload in the request body. If a /2/files/upload call results in a file with a size of 0 bytes, that should mean that the request body sent to /2/files/upload was empty. 

I'm not aware of any current issues on our side that would unexpectedly result in 0 byte files, so you should check if/why your network client is sending an empty request body in those cases. For example, check that your code has access to the expected file data it intended to put into the request body, etc and is successfully setting it. You may want to check the documentation for your platform/network client to see if you can enable some verbose logging, or use a debugger to troubleshoot in more detail.