[BUG] Use rawLow/rawHigh instead of parsedLow/parsedHigh in function - hasDecimalPart()

[Shailesh-Kumar-Singh]

Describe the bug

In the NumericNonDecimalMapper class, the getRangeMatchFilter method is responsible for handling range-based filtering by converting rawLow and rawHigh into Long values using numberType().parse().toLong().

However, the method currently checks for the presence of a decimal part at this location for rawLow and at this location for rawHigh using hasDecimalPart(parsedLow) and hasDecimalPart(parsedHigh). Since parsedLow and parsedHigh have already been converted to Long, any decimal information from rawLow and rawHigh is lost, making the check ineffective and leading to incorrect range adjustments.

To ensure correct validation, hasDecimalPart() should instead be called with the original rawLow and rawHigh values.

Related component

Search

To Reproduce

Use decimals as values for non-decimal numeric fields (byte/short/int/long) in query

Expected behavior

hasDecimalPart() should instead be called with the original rawLow and rawHigh values.

Additional Details

No response

[expani]

Thanks @Shailesh-Kumar-Singh for filing the issue. Looks like I missed this edge case even in the UTs
Will raise a fix soon.