-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] Total hits value behavior change in the response when using search_after in paginated search requests #9013
Comments
AFAIK this is not expected, do you have a simple repro? care to post it here, and maybe try to turn it into a YAML REST test? |
@dblock To reproduce:
After running these steps, total hits value for the three search requests were: v2.6.0: 6, 6, 6 |
Just to confirm, this is not happening in a single node setup (not cross cluster)? |
We test with cross cluster as that was the setup in our environment. i just tried with single cluster with 6 documents and was able to reproduce. Also, this only seems to happen if routing is used. |
Maybe related to #6596 ? |
I am not able to repro this on single node cluster. Below steps I tried.
Output
|
@tomchlee Could you help me verify if I am reproing this in right steps ? |
@gashutos Are you running your tests on 2.8 or 2.9? |
@gashutos your steps were mostly correct except for the search_after value for 2nd and 3rd searches; the search_after value should match the sort value in the last document in the returned hits array from the previous search response, so 2nd search (the first with search_after) should be like this:
and 3rd search should be:
Number of documents returned by the three search requests should be: 4, 2, 0. |
No luck on reproduction yet ! Tested on 2.8.0. |
@gashutos i didn't try it with single-node cluster; i tested with a single cluster with 2 data nodes as well as 2 clusters each with 2 data nodes. |
@tomchlee fine, output of 2 node cluster will also help. |
@gashutos Output (note hits.total.value is different in the last search response):
|
Thanks @tomchlee. At least on 2 node cluster (both data), this is not reproducing on both 2.8.0 & 2.9.0. |
#9683 , raised PR for fixing this. |
@gashutos our stateless frontend applications always display total search result counts via hits.total.value while going through paginated search_after queries, so if this behavior were to change, the applications would have to cache the value from the original query without search_after. |
@gashutos I really like your idea of enhancing the |
Describe the bug
Recently we upgraded to Opensearch 2.8.0 from 2.6.0 and noticed that a behavior change in the total hits value in the response when using search_after in paginated search requests. In this case, there were no ongoing indexing activities (same search requests would return the same number of documents/total hits). Once we started using search_after parameter in the search request to page through the results and came to the very last page result, if we make another search_after request using the sort value, the response returned with no documents and total hits value of 1, whereas the total hits in previous search_after responses all had the same value as in the initial search response. In 2.6.0, total hits value remained the same even for search_after request using the sort value of the very last page result (and no documents).
We also tried upgrading to 2.9.0 and performed the same test, and found the total hits value was not only different from the initial search_after request but also different for each search_after request with the total hits value decreasing for each subsequent request.
Is this behavior an intended change? Keep in mind, no new documents were indexed during the test.
To Reproduce
See description.
Expected behavior
Total hits value remained the same even for search_after request using the sort value of the very last page result (and no documents).
Plugins
Please list all plugins currently enabled.
Screenshots
If applicable, add screenshots to help explain your problem.
Host/Environment (please complete the following information):
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: