Search API returns 2 items while TotalRows is greater

[notariorob]

Target SharePoint environment

SharePoint Online

What SharePoint development model, framework, SDK or API is this about?

SharePoint REST API

Developer environment

None

What browser(s) / client(s) have you tested

• 💥 Internet Explorer
• 💥 Microsoft Edge
• 💥 Google Chrome
• 💥 FireFox
• 💥 Safari
• mobile (iOS/iPadOS)
• mobile (Android)
• not applicable
• other (enter in the "Additional environment details" area below)

Additional environment details

• browser version
• SPFx version
• Node.js version
• etc

Describe the bug / error

I'm performing a search using the following:
_api/search/query?querytext=%27benedict%27&querytemplate=%27{searchterms}%20AND%20PECVStatus:3%27
In this case, I know the querytext is part of a searchable managed property & PECVStatus is a queryable managed property. The query returns 2 results (rowCount), while stating there are a number of TotalRows of 6. If I search for other names that I know should also be found I have the same behaviour (2 results while more available).

It happens for some other querytexts even when not providing a querytemplate, but only some:
_api/search/query?querytext=%27Chris%27

However, if I add startrow=1 to the request, the rowCount returned is correct (except I'm missing the first item).
_api/search/query?querytext=%27benedict%27&querytemplate=%27{searchterms}%20AND%20PECVStatus:3%27&startrow=1

Steps to reproduce

Expected behavior

The number of results returned (RowCount) should be equal to TotalRows, at least in cases where RowLimit and RowsPerPage is not specified

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

[smolattack]

This is just how SharePoint Search "works". Every project I've worked on that relies on SPO Search has resulted in delays and compromises in the final product due to issues like this. In some cases, crawling can take months. You may also notice that new users might see even fewer results initially (for the first few days, weeks or however busy your tenant and shared infrastructure is).

You can log a call with Microsoft but they can only tell you how many tasks are queued for Search but they can't tell you any details (such as, where the majority of index requests are coming from and so on due to data privacy).

The only advise I can give you is to refrain from manually reindexing lists or sites. Only do that if a Microsoft engineer advises you to do it as it may delay your support call being escalated. This is because they might say that due to too many reindexing requests, you have to wait x number of days or weeks and then assess the situation which means your call gets put on hold (this has happened on a project I once worked on) .

[github-actions]

Thank you for taking the time to file an issue. We periodically archive older or inactive issues as part of our issue management process, which automatically closes them once they are archived.

If you’d like to understand more about why and how we handle archived (closed) issues, please see Our approach to closed issues.

We appreciate your contribution and if this is still an active issue with the latest SPFx versions, please do resubmit the details. We needed to perform a cleanup, so that we can start with a clean table with a new process. We apologize for the inconvenience this might cause.