sbrownnw Helpful | Level 6

I am not concerned about the actual error itself (yes, 503 errors can happen some times for a hosted service). I am reporting the error should not be specifically formatted as HTML, as that assumes a webpage or HTML capable client is making the API call.

I see, the folder being created after the file being restored was causing the failure I was seeing. Yes, you are correct, the folder is a different entity (not sure why, with a different Id) but the restored file has the same Id as the originally added one.

a list of the stop words would be appreciated also.

and when I change the query value to "txt", I get the following: I would expect every file expect the last one "/new rich text format.rtf" to be returned. Why is the .rtf file being returned with this query?

note, if I remove the fileExtensions filter arg, I still get no results searching for "test":

yes, I know how to get it. if we are recursing down a deep folder hierarchy it with ListFolderAsync and building it up in memory, it would sure be nice for all the subfolders and subfolders of subfolders all to have the parent FolderId without having to make additional calls.

I don't think you are understanding what we need. Given a File or Folder Metadata, I need its parent FolderId, all the time. Given the current API, it does not return that.

Feature request please for a File / Folder metadata item to always return its parent FolderId (whether it is shared or not). Both path and parent FolderId are very important metadata items for these types.

I still get a compilation error following your example (FileMetadata.Rev is a string):

Thanks

Ok. Strange, but ok. I tried the similar code and it does not compile with: mode: WriteMode.Update.Instance And it throws the same exception with: mode: new WriteMode().Update What do I use for Updating a file?

Thanks for the quick reply. Yes, your solution / workaround did make the response time better with using MaxRetriesOnError set to zero. I am still seeing response times of 6 to 12 seconds with this change. Seems like it should be 50% of the response times I am seeing when passing an expired token.

Running the same code with an invalid access token (empty string returns in less than 3 seconds on average):