Fix from and size parameter can be negative when searching

[gaobinlong]

Description

This PR fixes the bug of the from and size parameter in search api can be negative which can cause 500 error when searching, the cause of this bug is that we don't validate the two parameters specified in the request body, but if the two parameters are specified in the URL path, they would be validated. Even though from and size specified in the URL path will be validated, but because the default value of them are -1, currently we allow users to set them to -1 which is equivalent to 0, this PR also changes this behavior, -1 is not allowed to set for the two parameters.

Related Issues

#11290

Check List

• New functionality includes testing.
  • All tests pass
• New functionality has been documented.
  • New functionality has javadoc added
• Failing checks are inspected and point to the corresponding known issue(s) (See: Troubleshooting Failing Builds)
• Commits are signed per the DCO using --signoff
• Commit changes are listed out in CHANGELOG.md file (See: Changelog)
• Public documentation issue/PR created

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.

[github-actions]

Compatibility status:

Checks if related components are compatible with change 5689fe5

Incompatible components

Skipped components

Compatible components

Compatible components: [https://github.com/opensearch-project/custom-codecs.git, https://github.com/opensearch-project/asynchronous-search.git, https://github.com/opensearch-project/anomaly-detection.git, https://github.com/opensearch-project/flow-framework.git, https://github.com/opensearch-project/job-scheduler.git, https://github.com/opensearch-project/reporting.git, https://github.com/opensearch-project/cross-cluster-replication.git, https://github.com/opensearch-project/opensearch-oci-object-storage.git, https://github.com/opensearch-project/common-utils.git, https://github.com/opensearch-project/geospatial.git, https://github.com/opensearch-project/k-nn.git, https://github.com/opensearch-project/alerting.git, https://github.com/opensearch-project/neural-search.git, https://github.com/opensearch-project/performance-analyzer-rca.git, https://github.com/opensearch-project/security-analytics.git, https://github.com/opensearch-project/notifications.git, https://github.com/opensearch-project/ml-commons.git, https://github.com/opensearch-project/security.git, https://github.com/opensearch-project/index-management.git, https://github.com/opensearch-project/observability.git, https://github.com/opensearch-project/performance-analyzer.git, https://github.com/opensearch-project/sql.git]

[github-actions]

❌ Gradle check result for 35e0d3c: 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 644fd96: 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 b093f13: SUCCESS

[codecov]

Codecov Report

Attention: Patch coverage is 57.14286% with 3 lines in your changes are missing coverage. Please review.

Project coverage is 71.42%. Comparing base (b15cb0c) to head (d992aa9).
Report is 209 commits behind head on main.

Files	Patch %	Lines
...pensearch/rest/action/search/RestSearchAction.java	25.00%	1 Missing and 2 partials ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##               main   #13047     +/-   ##
===========================================
  Coverage     71.42%   71.42%             
- Complexity    59978    60639    +661     
===========================================
  Files          4985     5039     +54     
  Lines        282275   285426   +3151     
  Branches      40946    41336    +390     
===========================================
+ Hits         201603   203878   +2275     
- Misses        63999    64727    +728     
- Partials      16673    16821    +148     

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

[github-actions]

✅ Gradle check result for 5689fe5: SUCCESS

[gaobinlong]

@reta, could you help to review this PR, thanks!

[github-actions]

✅ Gradle check result for d992aa9: SUCCESS

[reta]

@reta, could you help to review this PR, thanks!

I have very limited availability this week, I will try to find the time, sorry about that @gaobinlong

[dblock]

This LGTM.

[dblock]

@gaobinlong Is there a scenario with size=0 is also an issue? Would you mind taking a look?

[opensearch-trigger-bot]

The backport to 2.x 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-2.x 2.x
# Navigate to the new working tree
pushd ../.worktrees/OpenSearch/backport-2.x
# Create a new branch
git switch --create backport/backport-13047-to-2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 ab7e914c3956ac206cf269ca345574882770a283
# Push it to GitHub
git push --set-upstream origin backport/backport-13047-to-2.x
# Go back to the original working tree
popd
# Delete the working tree
git worktree remove ../.worktrees/OpenSearch/backport-2.x

Then, create a pull request where the base branch is 2.x and the compare/head branch is backport/backport-13047-to-2.x.

[dblock]

@gaobinlong please be so kind to manually backport to 2.x?

[gaobinlong]

@gaobinlong Is there a scenario with size=0 is also an issue? Would you mind taking a look?

size=0 is a valid use case, which returns total hits count but not return the documents:
Request:

GET my-index/_search?size=0

Response:

{
  "took": 3,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 4,
      "relation": "eq"
    },
    "max_score": null,
    "hits": []
  }
}

[dblock]

size=0 is a valid use case, which returns total hits count but not return the documents:

Care to double check we have a test for it? Thanks.

[gaobinlong]

size=0 is a valid use case, which returns total hits count but not return the documents:

Care to double check we have a test for it? Thanks.

Yeah, there're multiple places that test size=0, like:

OpenSearch/rest-api-spec/src/main/resources/rest-api-spec/test/scroll/10_basic.yml

Line 230 in 9e9ab6b

size: 0

and

OpenSearch/rest-api-spec/src/main/resources/rest-api-spec/test/search/110_field_collapsing.yml

Line 301 in 9e9ab6b

size: 0