Onedrive-api-docs: Onedrive Api search request always returns an empty collection

[singhsmacmiller]

According to the Onedrive docs here when a search query is made, it should only return an empty collection if there were no items found. I know that there are items that exist that should show up in the response, however, no matter what I search for there are no results.

Here is the request I am making:
https://graph.microsoft.com/v1.0/users/{user-id}/drive/root/search(q='folder')

I have made sure that my request has the correct authorization header, am making a GET request, and that "{user-id}" is correct. At the root of OneDrive, there exists a driveitem with the name 'folder'. After searching for folder, I would expect my GET to come back with my driveitem object, however I only retrieve this empty collection:
{ "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#Collection(driveItem)", "value": [] }
Any ideas?

[ificator]

Hi @singhsmacmiller, what kind of token are you using to make the request? Is it app-only by any chance?

[singhsmacmiller]

@ificator
It is a token for apps. I use Microsoft graph to retrieve the token. Here is the page I referred to, in order to retrieve an access token.

It works for creating new folders, uploading files, adding/removing sharing permissions, listing children, and some other requests described in the onedrive api docs. I have only had trouble with search.

[Catmacey]

@ificator
Hi, did you have any luck resolving this? I'm having the same issue.
I'm using a very simple test folder structure and I can successfully search using the Graph Explorer, but I get no results when searching from my code. The search returns a HTTP:200 but the result collection is empty.
My code is authenticated using an App-only token and can access all the files/folders.
If I do a drives/#driveid#/items/#folderid#/children/ I can see the them.
I just can search for them...

[ificator]

We did manage to track down a likely cause for the app-only search issue and are working on a fix. Hopefully it'll be resolved in a couple of weeks.

[Catmacey]

@ificator Thank you for confirming this as a bug. Until such time as it is resolved, do you know of any workaround I could use? Not being able to perform searches is blocking my progress.

[Catmacey]

Today search appears to be working perfectly.
I ran my search test suite this morning and recieve a full set of results.
Have you implemented a fix for this bug already? If so, fantastic, great work!
If not. Any idea why it might work today. I've not changed my code nor my app registration.

[ificator]

Yes we did! But you may have noticed that the behavior has regressed again as we've had to temporarily disable it due to an unexpected side effect. We're working through that now though and hope to switch things back on early next week.

[Catmacey]

I did indeed notice the regression. But I understand the issue and really appreciate the update.

[ificator]

I think the fix should be pretty much deployed by now - so hopefully it should be working again, and remain that way!

[laguiz]

@ificator hi Brad, I'm using the Delegated Permissions and search does not work anymore for me. 2 weeks ago it worked properly (but I used at that time App Permissions). As we want to scope our rights to specific user we changed to Delegated.

We requested these permissions offline_access Sites.ReadWrite.All and so far all other API calls work properly (list files in the site, upload file, change meta data, ...) but search does not.

I also tried with https://developer.microsoft.com/graph/graph-explorer/ directly but no luck.

Works : https://graph.microsoft.com/v1.0/me/drive/root/search(q='a')
Does not : https://graph.microsoft.com/v1.0/sites/mydomaine.sharepoint.com,uuid1,uuid2/lists/uuid3/drive/root/microsoft.graph.search(q='Document')

Regarding uuids I'm pretty sure they are correct because I can do other things with the path (like browse items).

Is there a chance something is broken regarding search functionality (eg. https://docs.microsoft.com/en-us/graph/api/driveitem-search?view=graph-rest-1.0) ?

If not any hint?

Keep good work on Graph API.

_I searched on stackoverflow too : https://stackoverflow.com/questions/52446307/does-microsoft-graph-api-search-work-when-using-app-only-token
https://stackoverflow.com/questions/52446307/does-microsoft-graph-api-search-work-when-using-app-only-token_

[ificator]

Quick question: are the "Works" and "Does not" examples theoretically pointing at the same drive?

You can confirm by making a call like:

GET https://graph.microsoft.com/v1.0/me/drive?select=*,sharepointIds

and seeing if the SiteId,WebId, and ListId match those in your second query.

I don't see anything that's obviously wrong with what you're trying to do - and I can successfully use delegated to get back search results using the same style request as "Does not".

[laguiz]

Hi @ificator ,

Thank you for your feedback. We found the issue.

Regarding your question : no they are note the same drive. We where comparing simple search between /me and search on a site's collection.

The test is not relevant I guess.

To be able to search on a site collection it seems that we need read access on the ROOT site to make it works.

What we tried multiple times to be sure (all with delegated rights) :

1. Without access to the ROOT site :

• GET https://graph.microsoft.com/v1.0/me/drive?select=*,sharepointIds return properly with 4 sharePointIds.
• GET https://graph.microsoft.com/v1.0/sites/mydomaine.sharepoint.com,uuid1,uuid2/lists/uuid3/drive/root/microsoft.graph.search(q='Document') does NOT work (404 / itemNotFound / The resource could not be found.)

1. With access to the ROOT site (minimum read access) :

• GET https://graph.microsoft.com/v1.0/me/drive?select=*,sharepointIds return exaclty the same as above (same sharePointIds).
• GET https://graph.microsoft.com/v1.0/sites/mydomaine.sharepoint.com,uuid1,uuid2/lists/uuid3/drive/root/microsoft.graph.search(q='Document') works and return the expected elements.

Based on this we think that we need access (at least read) on the root site. That may be totally correct from your API design (I don't know) but this behavior sounds strange to us. In fact other endpoints (like browse items) does not need this access (this include upload file, etc.).

Do we miss something?

Note that it's not a problem for use to give this read access on the root site but it was hard for us to find the issue.

Feel free to ask more information if you need.

Thank you again.

[ificator]

The inconsistency between search and other API operations does seem strange - I'd expect search to have the same requirements as enumerating files. Do you happen to have a request-id and date values for one of the cases that returns the 404? They should both be in the JSON body of the failed request, but also in response headers.

[laguiz]

@ificator Hi, Is it safe to share here publicly? I can give you these ids next week (probably next thursday).

[ificator]

Yeah, they're safe - it's just a GUID and a timestamp, and they can only be used by us to see some more details about the request in question.

[laguiz]

Hi @ificator ,

Based on this call :
GET https://graph.microsoft.com/v1.0/sites/mydomaine.sharepoint.com,uuid1,uuid2/lists/uuid3/drive/root/microsoft.graph.search(q='Document')

If we don't have access on the ROOT site we have an http response Failure - Status Code 404 and here is the json :

{
    "error": {
        "code": "itemNotFound",
        "message": "The resource could not be found.",
        "innerError": {
            "request-id": "929afbc9-d34c-4cb7-800d-169e6237f66e",
            "date": "2019-02-26T08:41:38"
        }
    }
}

I give you an other one in case it help :

{
    "error": {
        "code": "itemNotFound",
        "message": "The resource could not be found.",
        "innerError": {
            "request-id": "ff65c876-9661-4cf9-9b79-9c4061102217",
            "date": "2019-02-26T08:45:40"
        }
    }
}

Thank you for the follow up.

[ificator]

Thanks @laguiz.

I also want to quickly make sure we're on the same page when it comes to "root site". Are you refering to the site with URL https://mydomaine.sharepoint.com or a site, say https://mydomaine.sharepoint.com/sites/foo, for which mydomaine.sharepoint.com,uuid1,uuid2 is a subsite?

[ificator]

Actually I think I can see what's going on - it's the former.

There's a class of issues we're currently tackling that appears to include this one. We're working on figuring out how to fix them now, and so long term you should not expect to need to give permission to the root site. However, it's a work around you can use to make sure you scenario functions as expected.

[ificator]

I've opened a new issue to track this since we've been reusing this old one and the root cause is definitely different.

[Madelene]

Hi @ificator - When using an app-only token, our search request returns an empty collection, despite having existing files.

Delegated permissions (personal OneDrive account, for example) returns items without a problem, in a search request.

I noticed in this thread, that there was a bug, awhile back, pertaining to this issue. Is it possible this bug has reared its ugly head again? Any insight is appreciated!

[shahtajk7]

Hi @ificator, we are facing the same issue as mentioned above. When using app-only token, our search results returns an empty collection.
I opened a new issue : https://github.com/OneDrive/onedrive-api-docs/issues/1394, really looking forward to hear back on this issue.

Thanks.