Skip approximation when track_total_hits is set to true

[prudhvigodithi]

Description

[Draft] Skip approximation when track_total_hits is set to true, example

curl -XPOST -H'Content-type: application/json' -kv localhost:9200/big5/_search -d '{
  "track_total_hits": true,
  "query": {
    "range": {
      "@timestamp": {
        "gte": "2023-01-01T00:00:00",
        "lt": "2023-01-03T00:00:00"
      }
    }
  }
}' | jq '.'

"track_total_hits": true goes to Integer.MAX_VALUE
"track_total_hits": false, goes to 10k
with no track_total_hits the default is 10

Related Issues

Part of #14406

Check List

• Functionality includes testing.
• API changes companion pull request created, if applicable.
• Public documentation issue/PR created, if applicable.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[prudhvigodithi]

Adding @harshavamsi @froh, please correct me if I'm wrong we should skip approximation when track_total_hits is set to true.

[github-actions]

✅ Gradle check result for d0fdc17: SUCCESS

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 72.61%. Comparing base (54e02a7) to head (360fb5e).
Report is 8 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main   #18017      +/-   ##
============================================
+ Coverage     72.47%   72.61%   +0.13%     
- Complexity    67034    67177     +143     
============================================
  Files          5478     5473       -5     
  Lines        310132   310036      -96     
  Branches      45087    45052      -35     
============================================
+ Hits         224775   225123     +348     
+ Misses        66960    66551     -409     
+ Partials      18397    18362      -35     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[froh]

Adding @harshavamsi @froh, please correct me if I'm wrong we should skip approximation when track_total_hits is set to true.

not @froh but @msfroh ;-)

[github-actions]

❌ Gradle check result for e6adbd3: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[github-actions]

❕ Gradle check result for a1453f8: UNSTABLE

Please review all flaky tests that succeeded after retry and create an issue if one does not already exist to track the flaky failure.

[github-actions]

Hello!
We have added a performance benchmark workflow that runs by adding a comment on the PR.
Please refer https://github.com/opensearch-project/OpenSearch/blob/main/PERFORMANCE_BENCHMARKS.md on how to run benchmarks on pull requests.

[prudhvigodithi]

@harshavamsi @msfroh Just a follow up here please let me know if this change make sense.
Thanks

[harshavamsi]

LGTM! thanks for this change. Can we also update the changelog.

[prudhvigodithi]

Thanks, updated the changelog.

[github-actions]

❌ Gradle check result for 360fb5e: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[github-actions]

❌ Gradle check result for 360fb5e: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[github-actions]

✅ Gradle check result for 360fb5e: SUCCESS

[prudhvigodithi]

Adding @andrross @froh @cwperks to see if we can merge this PR.
Thanks

[froh]

Adding @andrross @froh @cwperks to see if we can merge this PR. Thanks

@prudhvigodithi: again, it's @msfroh, not @froh ... thx

[prudhvigodithi]

@prudhvigodithi: again, it's @msfroh, not @froh ... thx

Apologies for the wrong tag again.

[andrross]

@prudhvigodithi Is this an important bug fix that should be backported to the 3.0 release, or can it wait for 3.1?

[prudhvigodithi]

Thanks Andrew yes we should backport it, just added a backport label.

[opensearch-trigger-bot]

The backport to 3.0 failed:

The process '/usr/bin/git' failed with exit code 128

To backport manually, run these commands in your terminal:

# Navigate to the root of your repository
cd $(git rev-parse --show-toplevel)
# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add ../.worktrees/OpenSearch/backport-3.0 3.0
# Navigate to the new working tree
pushd ../.worktrees/OpenSearch/backport-3.0
# Create a new branch
git switch --create backport/backport-18017-to-3.0
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 c5e55b0409287d67a9245a6af1db7ef32c394ffb
# Push it to GitHub
git push --set-upstream origin backport/backport-18017-to-3.0
# Go back to the original working tree
popd
# Delete the working tree
git worktree remove ../.worktrees/OpenSearch/backport-3.0

Then, create a pull request where the base branch is 3.0 and the compare/head branch is backport/backport-18017-to-3.0.