A Microsoft file hosting and synchronization service.
The behavior is due to how the OneDrive/Graph search API works and its limitations, not to a problem with the file itself.
Key points from the documented behavior:
-
search(q=...)is not a full, immediate index of all items-
GET /me/drive/root/search(q='{search-text}')searches items using an index that can lag behind recent changes. Newly created or recently modified files may not appear until the index is updated. - The query text is matched across several fields (filename, metadata, and file content), but only against what has been indexed so far.
-
- Search scope and paging
-
GET /me/drive/root/search(q='{search-text}')searches under the root item of the drive hierarchy. - If there are many matches, results are paged and an
@odata.nextLinkis returned. Only the first page is returned initially; additional pages must be requested explicitly. If the result set is large and paging is not followed, some matching items will not be seen.
-
- Differences and limitations in OneDrive search
- The OneDrive/SharePoint release notes call out that item searching has specific limitations and differences from other operations. For OneDrive for Business and SharePoint, search does not return some properties (
createdBy,modifiedBy,parentReference), and there are other behavioral differences compared to direct item access. - While the notes focus on business/SharePoint, they highlight that search behavior is not identical to direct addressing (
/items/{item-id}) and can omit or delay items.
- The OneDrive/SharePoint release notes call out that item searching has specific limitations and differences from other operations. For OneDrive for Business and SharePoint, search does not return some properties (
- Why
GET /me/drive/recentand direct path access work-
GET /me/drive/recentreturns items recently used by the signed-in user and is based on recent activity, not the same index used bysearch. It can therefore show items that are not yet visible insearch. - Direct access by ID or path (
/me/drive/items/{item-id}or/me/drive/root:/path/to/file) does not depend on the search index; it reads the item directly from the drive and will always find an existing file.
-
Practical implications for this scenario:
- A newly created Excel file like
Book.xlsxcan be:- Accessible directly by
/me/drive/items/{id}or by path. - Visible in
/me/drive/recent. - Temporarily missing from
/me/drive/root/search(q='.xlsx OR .xls OR .xlsm')until the search index updates.
- Accessible directly by
- If many Excel files exist, ensure that:
- All pages of search results are followed via
@odata.nextLink. -
$topis used appropriately if a specific page size is needed.
- All pages of search results are followed via
If all pages are being followed and the file still does not appear after some time, the recommended approach is to rely on:
- Direct addressing by path or ID for critical operations, and
-
searchonly as a best-effort discovery mechanism, understanding that it may not be complete or real-time.
References: