Ascending sorting in RecentViewCount causes 500 error when pagination is being used

[benjacernuda]

Target SharePoint environment

SharePoint Online

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

SharePoint REST API

Developer environment

Windows

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

We are doing a REST API search query where are are trying to sort (ascending) the results using RecentViewCount managed property

If we try to paginate the results we get a 500 internal error. We don't have this error doing the same if we sort for the same property (RecentViewCount) but descending

Very weird error because it seems it depends of the number of row per page, row limit, etc..

I have tried this in 3 different tenants with the error is all of them

Everytime if I change the sorting clause to descending the query works fine

Many thanks in advance

Steps to reproduce

1. Open the SharePoint Search Query Tool and connect to a tenant
2. Add for example the text ContentTypeId:0x010100* in the Query Template field
3. Add * in the Query Text field
4. Add RecentViewCount:ascending in the Sort List field
5. Row Limit: 24, Row per Page:24, Start: 72
6. I have noticed that if I reduce the row per page and row limit it seems the error doesn't happen

Expected behavior

HTTP/1.1 500 Internal Server Error
{"error":{"code":"-1, Microsoft.Office.Server.Search.REST.SearchServiceException","message":{"lang":"en-US","value":"An unknown error occurred."}}}

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

[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.