Fix bug "Assertion framework(Yaml Rest test): numeric comparison fails when comparing Integer vs Long (or Float vs Double)"

[laminelam]

Resolves #19323

The numerical comparison classes (gt, gte, lt and lte) share more than 90% of the code. Refactored the 4 classes by extracted the common code into a super class.

Updated the convertActualValue method to normalize mixed numeric types to a common upper type.

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.

Summary by CodeRabbit

• Bug Fixes

  • Resolved numeric comparison failures in YAML REST assertions when comparing different numeric types (Integer vs Long, Float vs Double).

• Tests

  • Enhanced test coverage for cross-type numeric comparisons in YAML REST assertions.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[github-actions]

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

[laminelam]

Hi @sandeshkr419
Can you, or somebody else look at this?

[sandeshkr419]

Thanks for fixing this and refactoring the code. I do have some clarifying questions.

[github-actions]

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

[andrross]

@sandeshkr419 Can you take another look at this?

[github-actions]

❌ Gradle check result for 596a2b6: 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 596a2b6: 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 3ca23d2: SUCCESS

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 73.29%. Comparing base (d47931e) to head (cc5b742).
⚠️ Report is 10 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main   #19376      +/-   ##
============================================
- Coverage     73.30%   73.29%   -0.01%     
- Complexity    71732    71756      +24     
============================================
  Files          5793     5793              
  Lines        328056   328110      +54     
  Branches      47245    47256      +11     
============================================
+ Hits         240476   240495      +19     
+ Misses        68264    68255       -9     
- Partials      19316    19360      +44     

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

[opensearch-trigger-bot]

This PR is stalled because it has been open for 30 days with no activity.

[github-actions]

✅ Gradle check result for 321fb54: SUCCESS

[github-actions]

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

[laminelam]

Hi @andrross
This PR has 2 approvals. Is it good for a merge or do we need more review?

[prudhvigodithi]

This PR has 2 approvals. Is it good for a merge or do we need more review?

Can you please fix the changelog file conflict, the new commit should start the Gradle check CI run again. We can move forward once all the CI's are green. Thanks

[github-actions]

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

[coderabbitai]

Walkthrough

A structural refactoring of the YAML REST test assertion framework extracts ordering comparison logic (greater-than, less-than variants) into a shared abstract base class, consolidating numeric type normalization and comparison handling. Additionally, the base Assertion class is updated to parse numeric values more robustly, addressing failures when comparing Integer vs Long or Float vs Double values.

Changes

Cohort / File(s)	Summary
Assertion Framework Consolidation test/framework/src/main/java/org/opensearch/test/rest/yaml/section/GreaterThanAssertion.java, GreaterThanEqualToAssertion.java, LessThanAssertion.java, LessThanOrEqualToAssertion.java	Refactored to extend new OrderingAssertion base class instead of Assertion; delegated parsing to shared parseOrderingAssertion() helper; replaced doAssert() logic with abstract relation() method returning comparison operator; converted errorMessage() from private to protected override.
New Ordering Assertion Base Class test/framework/src/main/java/org/opensearch/test/rest/yaml/section/OrderingAssertion.java	New abstract class providing unified comparison framework: defines Relation enum (GT, GTE, LT, LTE); implements shared doAssert() with type normalization, comparison, and error handling; provides parseOrderingAssertion() static helper for subclass parsing; includes normalizePair() utility to coerce numeric types to common comparable forms.
Numeric Type Parsing test/framework/src/main/java/org/opensearch/test/rest/yaml/section/Assertion.java	Modified convertActualValue() to attempt Long parsing before Integer fallback when expected value is Integer, enabling cross-type numeric comparisons without ClassCastException.
Test Coverage test/framework/src/test/java/org/opensearch/test/rest/yaml/section/AssertionTests.java	Added cross-type comparison tests exercising Integer vs Long, Float vs Double, and mixed floating-point type scenarios for both GreaterThanAssertion and LessThanAssertion.
Documentation CHANGELOG.md	Added entry documenting bug fix for numeric comparisons across boxed numeric types (Integer/Long, Float/Double) in Assertion framework.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Key areas requiring attention:

• OrderingAssertion base class – Verify correctness of normalizePair() logic for all numeric type promotions (Integer→Long, Float→Double, etc.) and ensure exception handling in doAssert() covers edge cases
• Refactored assertion subclasses – Confirm that delegating to parseOrderingAssertion() preserves behavior for all four variants (GT, GTE, LT, LTE) and that the relation() method implementations are consistent
• Assertion.convertActualValue – Validate that the Long-first parsing strategy correctly handles edge cases (MAX/MIN values, NumberFormatException paths)
• Test coverage – Ensure new cross-type comparison tests exercise all affected assertion types and properly validate expected exceptions/messages

Poem

🐰 Numbers dance in harmony at last,
Long and Integer's type-mismatch curse is passed,
A shared base class with wisdom to normalize,
Comparisons now flow—no more ClassCast surprise!
The ordering assertions hop, skip, and assert with grace. ✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 7.14% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The PR title accurately and specifically describes the bug fix: numeric comparison failures in YAML REST test assertions when comparing different boxed numeric types (Integer vs Long, Float vs Double).
Description check	✅ Passed	The PR description is complete and follows the template structure, including issue resolution, description of changes, and all required checklist items.
Linked Issues check	✅ Passed	All coding requirements from issue #19323 are met: numeric type normalization in convertActualValue, extraction of common code into OrderingAssertion superclass, and comprehensive cross-type test coverage.
Out of Scope Changes check	✅ Passed	All changes directly address the linked issue: CHANGELOG entry documents the fix, Assertion.convertActualValue is updated for type normalization, and four assertion classes are refactored to extend OrderingAssertion with tests added.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (2)

test/framework/src/test/java/org/opensearch/test/rest/yaml/section/AssertionTests.java (1)

114-114: Consider adding tests for GreaterThanEqualToAssertion and LessThanOrEqualToAssertion.

While the shared OrderingAssertion base class means these assertions use the same comparison logic, adding at least one cross-type test per assertion type would improve test coverage completeness and ensure all relation operators work correctly.

test/framework/src/main/java/org/opensearch/test/rest/yaml/section/OrderingAssertion.java (1)

127-137: Consider BigDecimal/BigInteger handling.

The current implementation converts all non-floating numbers to Long, which could lose precision for BigInteger or BigDecimal values. However, since JSON parsing typically yields Integer/Long/Double, this is unlikely to be an issue in practice for YAML REST tests.

If BigDecimal/BigInteger support is needed in the future, consider handling them explicitly:

 private static Tuple<Object, Object> normalizePair(Object a, Object b) {
     if (a instanceof Number aNum && b instanceof Number bNum) {
+        // BigDecimal/BigInteger: compare directly without conversion
+        if (a instanceof java.math.BigDecimal || b instanceof java.math.BigDecimal
+            || a instanceof java.math.BigInteger || b instanceof java.math.BigInteger) {
+            return Tuple.tuple(a, b);
+        }
         boolean isFloating = aNum instanceof Float || aNum instanceof Double || bNum instanceof Float || bNum instanceof Double;

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 0449ce8 and cc5b742.

📒 Files selected for processing (8)

• CHANGELOG.md (1 hunks)
• test/framework/src/main/java/org/opensearch/test/rest/yaml/section/Assertion.java (1 hunks)
• test/framework/src/main/java/org/opensearch/test/rest/yaml/section/GreaterThanAssertion.java (1 hunks)
• test/framework/src/main/java/org/opensearch/test/rest/yaml/section/GreaterThanEqualToAssertion.java (1 hunks)
• test/framework/src/main/java/org/opensearch/test/rest/yaml/section/LessThanAssertion.java (1 hunks)
• test/framework/src/main/java/org/opensearch/test/rest/yaml/section/LessThanOrEqualToAssertion.java (1 hunks)
• test/framework/src/main/java/org/opensearch/test/rest/yaml/section/OrderingAssertion.java (1 hunks)
• test/framework/src/test/java/org/opensearch/test/rest/yaml/section/AssertionTests.java (2 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (21)

• GitHub Check: gradle-check
• GitHub Check: assemble (25, windows-latest)
• GitHub Check: assemble (25, ubuntu-latest)
• GitHub Check: assemble (25, ubuntu-24.04-arm)
• GitHub Check: assemble (21, ubuntu-latest)
• GitHub Check: assemble (21, windows-latest)
• GitHub Check: assemble (21, ubuntu-24.04-arm)
• GitHub Check: Analyze (java)
• GitHub Check: precommit (25, windows-latest)
• GitHub Check: precommit (25, ubuntu-24.04-arm)
• GitHub Check: detect-breaking-change
• GitHub Check: precommit (25, macos-15)
• GitHub Check: precommit (25, macos-15-intel)
• GitHub Check: precommit (21, windows-2025, true)
• GitHub Check: precommit (21, ubuntu-24.04-arm)
• GitHub Check: precommit (21, macos-15)
• GitHub Check: precommit (21, windows-latest)
• GitHub Check: precommit (21, ubuntu-latest)
• GitHub Check: precommit (25, ubuntu-latest)
• GitHub Check: precommit (21, macos-15-intel)
• GitHub Check: Mend Security Check

🔇 Additional comments (10)

CHANGELOG.md (1)

97-97: LGTM!

The changelog entry is correctly placed under the "Fixed" section and accurately describes the bug fix for numeric type comparison failures in the YAML REST test assertion framework.

test/framework/src/main/java/org/opensearch/test/rest/yaml/section/GreaterThanEqualToAssertion.java (1)

45-62: LGTM!

The refactoring cleanly delegates to the new OrderingAssertion base class. The relation() and errorMessage() template methods are properly implemented, and the parsing logic is now consolidated.

test/framework/src/test/java/org/opensearch/test/rest/yaml/section/AssertionTests.java (2)

70-87: LGTM!

Good coverage of cross-type numeric scenarios for GreaterThanAssertion. The tests validate that mixed Integer/Long and Float/Double comparisons work correctly without throwing ClassCastException.

---

97-114: LGTM!

The LessThanAssertion tests properly validate both successful cross-type comparisons and failure scenarios. Using expectThrows(AssertionError.class, ...) confirms that comparison failures now produce AssertionError instead of ClassCastException, which was the core bug being fixed.

test/framework/src/main/java/org/opensearch/test/rest/yaml/section/LessThanOrEqualToAssertion.java (1)

45-62: LGTM!

The refactoring is consistent with the other ordering assertion classes. The previous review comment about passing the Relation.LTE enum directly has been addressed—the implementation now uses the Relation enum throughout.

test/framework/src/main/java/org/opensearch/test/rest/yaml/section/GreaterThanAssertion.java (1)

44-61: LGTM!

The refactoring eliminates code duplication by extending OrderingAssertion. The implementation is consistent with the other ordering assertion classes and follows the template method pattern correctly.

test/framework/src/main/java/org/opensearch/test/rest/yaml/section/LessThanAssertion.java (1)

45-62: LGTM!

Clean refactoring that properly delegates to the shared OrderingAssertion base class. The relation() and errorMessage() implementations are correct for less-than semantics, and the parsing correctly uses the shared parseOrderingAssertion mechanism.

test/framework/src/main/java/org/opensearch/test/rest/yaml/section/OrderingAssertion.java (3)

30-33: LGTM!

Well-structured abstract base class that properly extends Assertion and establishes the contract for ordering assertion subclasses.

---

56-72: LGTM!

The shared parsing logic is well-implemented with proper validation that the expected value is Comparable. The factory pattern allows clean instantiation of concrete assertion types.

---

74-109: LGTM!

The doAssert implementation correctly chains convertActualValue → normalizePair before comparison. The switch expression handles all Relation cases exhaustively, and the ClassCastException catch provides a useful fallback error message.

[github-actions]

❌ Gradle check result for cc5b742: 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 cc5b742: 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 cc5b742: SUCCESS