"ItemNotFound" when uploading file

[tipa]

using Graph.NET Nuget package 1.17.0 in my UWP app

Expected behavior

I am able to upload a file to OneDrive (into the apps app folder).

Actual behavior

An exception is thrown (see below) - but only sometimes! I feel like it mostly (or only) happens the first time the app tries to upload something to its (newly created) app folder. It usually (but not always!) succeeds on a second attempt.

Microsoft.Graph.ServiceException: Code: itemNotFoundMessage: Item does not existInner error at Microsoft.Graph.HttpProvider.d19.MoveNext() + 0x5ac--- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() + 0x21 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task) + 0x5c at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task) + 0x44 at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task) + 0x1c at Microsoft.Graph.BaseRequest.d36.MoveNext() + 0x475--- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() + 0x21 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task) + 0x5c at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task) + 0x44 at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task) + 0x1c at Microsoft.Graph.BaseRequest.d32`1.MoveNext() + 0x12f--- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() + 0x21 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task) + 0x5c at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task) + 0x44 at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task) + 0x1c at Diarium.OneDriveHelper.d15.MoveNext() + 0x2ad--- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() + 0x21 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task) + 0x5c at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task) + 0x44 at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task) + 0x1c at System.Runtime.CompilerServices.ConfiguredTaskAwaitable.ConfiguredTaskAwaiter.GetResult() + 0xb at Diarium.OneDriveHelper.d__1.MoveNext() + 0x150e

Steps to reproduce the behavior

static async Task UploadFile(GraphServiceClient graphClient, string filePath, MemoryStream stream)
{
    if (stream.Length > 4194304)
    {
        var session = await graphClient.Drive.Special.AppRoot.ItemWithPath(filePath).CreateUploadSession().Request().PostAsync();
        await new ChunkedUploadProvider(session, graphClient, stream).UploadAsync();
    }
    else
    {
        await graphClient.Drive.Special.AppRoot.ItemWithPath(filePath).Content.Request().PutAsync<DriveItem>(stream);
    }
}

Issue occured on both the "beta" and "v1.0" endpoint

This issue was also raised here: https://github.com/microsoftgraph/msgraph-sdk-dotnet/issues/385

[ghost]

Thank you for your contribution to OneDrive API Docs. We will be triaging your incoming issue as soon as possible.

[chackman]

Thanks for your feedback; however, we need more information to understand the issue further.

Could you please provide recent values for the following response headers:

• Date (in UTC, please)
• request-id
• SPRequestGuid (for requests made to OneDrive for Business)

[chackman]

I understand that you've already provided those values before, but they are unfortunately too old for us to be able to look up. Thanks for your patience.

[tipa]

Thanks for your response! Is that recent enough? request-id: 52bec5f1-86b7-428c-9723-2e08a1924dce, date: 8/27/2019 3:17:11 PM request-id: 085d7743-8cc4-4a1c-8d8c-e9e4f7a17489, date: 9/8/2019 3:03:20 AM (unfortunately not guaranteed to be UTC)

[chackman]

Yes, thanks! Upon further investigation, this is an issue that we've added to our backlog to address.

[tipa]

Thanks for the info. Can you maybe give some information about why the problem is happening and if there is any workaround on my side? Also, any idea when you will find the time to fix it? Quite a few of my users are encountering this problem.

[chackman]

This can happen if there are multiple concurrent requests to write to the same app folder.

[tipa]

I already was told something similar here: https://github.com/microsoftgraph/msgraph-sdk-dotnet/issues/385#issuecomment-502293182

When first accessing the App folder, I am making sure there are no concurrent requests but even then the error happens for some users. For some of those users the error is persistent, for some it occurs just once. Either way, this very much looks like a bug in the OneDrive service to me as concurrent requests should be allowed. Sending files sequentially would significantly slow down my syncing process.

[tipa]

Any updates on this?

[tipa]

Could you at least give me any hope that this issue will be resolved at some point in the future? It prevents some users of mine to use my app to it's full extend.

[chackman]

While this is on our backlog, we don't have an ETA that we can share at this time.

[arsnyder16]

@chackman @tipa

I am able to reproduce a similar issue that seems unrelated to concurrent requests. If one of my users shares a file from their one drive to another user with write permissions, then anything time the uploadUrl is used they receive a 404 "ItemNotFound". This includes trying to delete the uploadsession.

I haven't tested this across tenants, All the issues we see are two users sharing files between their onedrives within the same tenant.

If using the standard upload for small files <4MB these scenarios work fine. If the user shares the folder that the file is contained then the upload sessions seem to work as expected.

My suspicion is that an upload session is simply creating a temporary file to upload to, but when that temporary file is created the permissions are not transferred from the original file, hence being invisible(404) to all users other than the user "owning" the drive.

I am using the node sdk, but i think this is all one in the same and is a service side issue. Delaying or retrying seems to have no effect they always fail with 404

[arsnyder16]

Just an update to my comments, so we did some more digging. We are seeing inconsistent behavior between some files from the same users onedrive, even within the same folder. Some files the uploads work fine every time and other file the upload session is created but when you try to use the upload url you get a 404 "ItemNotFound" response.

here are some details from the failed uploads

Upload Session creation: client-request-id: c8ed8467-8893-7f07-3489-d04f76e113be request-id: e3200d76-a160-4630-ac63-05179924df92

Failed PUT on the uploadUrl request-id: f671369f-1021-a000-7eb6-32b87c2884b7 sprequestguid: f671369f-1021-a000-7eb6-32b87c2884b7 guid in upload url query params: '9091e061-fda2-4d02-adb1-958a1e47cc60' Response: {"error":{"code":"itemNotFound","message":"The resource could not be found."}}

Are there any more details that i can supply?

[tipa]

@chackman any updates regarding this bug? It is still present and happens for many of my users. If there's anything I can do to provide additional info, please let me know

[dlong11]

@chackman @tipa has this been fixed?

[tipa]

No, not fixed

[chackman]

Could you please provide updated request information? I'll tag so our robot will identify what information we need.

[ghost]

Thanks for your feedback; however, we need more information to understand the issue further. If you have not provided the following information, could you please provide the following?

Could you please provide the following response headers:
- Date (in UTC, please)
- request-id
- SPRequestGuid (for requests made to OneDrive for Business)
Please provide as recent values as possible.

Could you please describe the steps to reproduce the bug in sufficient detail for another person to be able to reproduce it?

Could you please provide sample requests and responses that illustrate the issue that you are encountering?

Could you please describe the behavior you expected to occur when performing the action?

[tipa]

Sure, some examples:

date: 2020-09-29T08:43:36 request-id: c2f29edd-d4a4-4350-afa5-c75907fe040b

date: 2020-10-03T19:41:09 request-id: 0faa458e-470c-40fd-844c-e69ec02b6bd8

date: 2020-10-21T11:43:18 request-id: 185967d8-3af9-4a6d-8242-966f5ae46da6

date: 2020-10-19T04:15:05 request-id: 6d018bc3-2194-4123-bee4-83ebf43e2f4e

[tipa]

Does that help @chackman?

[chackman]

It does. To be clear does this issue only occur shortly after creating the app folder?

[tipa]

Yes, in my code I am trying to upload a file into the app folder. For the majority of my users, this works without problems. However, for some users this exception is being thrown. From what I can tell reading the logs, for the users that this problem occurs, it occurs repeatedly and not only once.

[chackman]

Thanks for the information. Could you please share some more recent request-id's and times? When we originally looked this up we couldn't find them.

[tipa]

date: 2020-11-01T18:48:59 request-id: b0efb1ae-dba6-45b2-b7d9-20f6e63f36f8

date: 2020-11-20T22:24:56 request-id: 52a06629-75da-40bd-911d-4b3f6adc9a53

date: 2020-11-20T20:33:08 request-id: 8a02f39f-00a6-43e6-8f62-ceb531b5a14d

date: 2020-11-17T03:24:18 request-id: c35cb21e-4636-46f0-bc0a-36b42b44042d

Hope this helps. Or are those too old?

[chackman]

Thanks. About the requests for the users where this is always happening repeatedly - does the request have a file path within the special folder (is filePath non-empty)?

[tipa]

Hmm not 100% sure what you mean but I only work in the "root app folder", so I think no - the "path" parameter only contains the file name.

[chackman]

The URL in the PUT request should contain a file path, even if it's just the new file name.

Since your application is uploading to a special folder, the PUT request URL should look something like this: PUT https://graph.microsoft.com/v1.0/me/drive/special/approot:/newFile.txt:/content Does that API URl contain the segment with "newFile.txt"?

[tipa]

I generally use an upload session with an URL like this: https://graph.microsoft.com/v1.0/me/drive/special/approot:/data_v4.wh:/microsoft.graph.createUploadSession If that fails with ItemNotFound, I fall back to the simple file upload: https://graph.microsoft.com/v1.0/me/drive/special/approot:/data_v4.wh:/content Sometimes, the fallback then succeeds, but often it does not

[zachzi]

Hi Tipa,

If you can still reproduce the issue, we could try collecting extra information with a diagnostic trace. 1) Go to: https://onedrive.live.com/?v=traceme 2) Check all the check boxes, and click start trace 3) Wait 1 minute, then perform the repro for your issue 3) Send us the paths to the traces in the text boxes:

[tipa]

I cannot reproduce this problem locally, it just happens for some of my app users, unfortunately.

[raydixon]

@zachzi I can consistently reproduce this using @tipa's app. Below are the values from a trace I just did while reproducing it.

Calls on my data

522EFA955FB5B148\2020-12-17_164948

Calls I make

522EFA955FB5B148\2020-12-18_153714

[tipa]

Users told me that when this problem happens, the "AppRoot"-folder is already created in the "Apps" folder. After deleting that folder, the problem disappears. Maybe this helps with finding the cause... This problem is already 2 years old (first reported here) and I am really surprised that not more developers are facing this issue...

[k-tsoi]

@tipa were any permissions changed on the App root folder or the root folder of the OneDrive?

[tipa]

No, I don't know why a user would do that. I wouldn't even know how to do that.

[k-tsoi]

@tipa does the issue reoccur again after a while for the user once they delete and recreate the folder? Or does deleting and recreating the folder fix the issue completely?

[raydixon]

@tipa and/or @k-tsoi can one of you please tell me how to find the folder? I'm happy to try the troubleshooting step of deleting and recreating it, but I can't find the Applications folder nor the WorkingHours folder.

[tipa]

@k-tsoi I have not heard of a user yet reported that the issue reoccurred after the folder was deleted. @raydixon the folder should be in your OneDrive root as described here. However, the folder can also be moved into other subfolders manually. Are other apps able to use your OneDrive's app folder or is WorkingHours the only one failing? Maybe you can write me a mail so we can try some other steps investigate this?

[raydixon]

@tipa and @k-tsoi In looking for the WorkingHours folder in my OneDrive, I discovered that, a long time ago, I moved the Apps folder from my Documents folder into a different folder that I created in the root of my OneDrive. After I moved the Apps folder back to my Documents folder, my WorkingHours app (on Windows and my Android phone) are syncing without a problem using OneDrive.

Oddly, some other apps had folders in the Apps and were working fine before and after I moved the Apps folder back to my Documents folder. Namely, Fresh Paint, Graph explorer (official site), Office Lens, and SMS Backup and Restore. The Graph explorer (official site) folder got created while I was using the API to try to find the WorkingHours folder, before I moved the Apps folder back, and continues to work as expected after I moved it.

[chackman]

@raydixon regarding your app's AppRoot folder, was it originally provisioned through the special folder API?

[raydixon]

@chackman It's been quite a while ago, but I'm pretty certain it must have been provisioned through whatever the Fresh Paint app used to create it because the value for the createdDateTime property for the Apps folder is 2016-02-10T04:24:42.156Z and for the Fresh Paint folder in it is 2016-02-10T04:24:42.277Z.

I hope this helps.

[chackman]

Your app's special folder should be separate from other app's special folders. Had it been created using the special folders API?

[tipa]

I think they have always been separate, the problem was that the "Applications" folder (which contains all the various apps "AppRoot" folders) was in the wrong subfolder and therefore accessing it seemed to be not possible. I think both me and @raydixon don't know for sure what API Fresh Paint is using to create the special folders.

[raydixon]

@chackman, as @tipa suggested, each of the apps that created special folders for me, including the one from @tipa, has its own special folder under the Apps folder. What I was trying to communicate in my response above is that I speculate that the Fresh Paint app must have initiated the creation of the Apps folder, based on the very close creation times and the creation times of the other folders in the Apps folder.

The strange thing is that other apps were able to work fine even after I moved the Apps folder. Only the WorkingHours app, from @tipa, had problems when the Apps folder was in a different location. It seems like whatever API the other apps are using should be documented as the best practice so developers like @tipa can use the same approach and not have to deal with a user moving folders in OneDrive.

[k-tsoi]

@raydixon @tipa to confirm that both of you are unblocked for this issue? if so we will close this. It should be noted that the specialFolders API is the correct API for other apps to be using for special folders. If this issue comes back up for a user who had their special folder recently created please reopen this issue

[raydixon]

@k-tsoi I confirm that this is not an issue for me, but I can't speak for @tipa who is the developer who opened the issue.

[tipa]

@k-tsoi this problem is not fixed and I still have plenty of request-ids of API calls that fail with itemNotFound, e.g. date: 2021-03-19T07:42:34 request-id: 20a85d32-5b31-4628-b7bd-5561d777703c

[tipa]

@k-tsoi this error is still present and I am receiving multiple support mails from users per week because parts of my app is not functioning properly as a result. It feels I have sent hundreds of request-ids already, but seemingly they all don't help in finding the issue. Is there anything else I can do? It's increasingly difficult for me to understand why there seems to be no willingness to fix this bug...

[zachzi]

@raydixon / @tipa very sorry, but it seems like I forgot to pull the traces @raydixon supplied, but since they are too old now, I can no longer retrieve them. Would it be possible to get new ones? That would be the best chance for us to figure out why this is occurring.

[raydixon]

@zachzi I just tried moving my Apps folder to repro the problem and it doesn't repro, now. Maybe it's only when the folder for the app doesn't already exist somewhere if OneDrive that the problem occurs.

@tipa I hope you have some current traces. 🤞

[tipa]

@zachzi absolutely, I have plenty of new ids, many of them are coming in every day :)

date: 2021-04-27T16:39:59 request-id: 9fccb3df-eeff-434b-8101-23388860a542 date: 2021-04-28T07:27:58 request-id: ff3e2610-7d1a-4024-9e34-3127fc8cbff2 date: 2021-04-29T07:49:04 request-id: 0cd0b329-7b47-4df8-86e9-16c112998f86