Fix: terms_set query throws descriptive error when minimum_should_mat…

[Aman199825]

…ch is missing (#18261)

Description

[Describe what this change achieves]

Related Issues

Resolves #[Issue number to be closed when this PR is merged]

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.

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🧪 PR contains tests

🔒 No security concerns identified

✅ No TODO sections

🔀 No multiple PR themes

⚡ No major issues detected

[github-actions]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
General	Validate required parameters first The validation should occur before the values.isEmpty() check to fail fast and provide clearer error messages. Users should know about missing required parameters before checking if values are empty. server/src/main/java/org/opensearch/index/query/TermsSetQueryBuilder.java [249-254] if (minimumShouldMatchField == null && minimumShouldMatchScript == null) { throw new IllegalArgumentException( "[" + NAME + "] requires either a [minimum_should_match_field] " + "or [minimum_should_match_script] to be set" ); } +if (values.isEmpty()) { + return Queries.newMatchNoDocsQuery("No terms supplied for \"" + getName() + "\" query."); +} Suggestion importance[1-10]: 3 __ Why: The suggestion proposes reordering validation checks for fail-fast behavior. However, the current order is already reasonable since both validations will execute before query creation. The improvement is marginal and mostly stylistic, as both checks occur early in the method.	Low

[github-actions]

❌ Gradle check result for c2de375: 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?