[Bug] Filter parser rejects zero floating-point literals

[yuluo-yx]

Runtime platform environment

macOS; reproduced with SelectorParser in the filter module.

RocketMQ version

Branch: develop
Git commit: fd0c95920e0deac96ce2ae27442747cc5e65e930

JDK Version

Eclipse Temurin 17.0.19+10

Describe the Bug

ConstantExpression.createFloat uses Double.MIN_VALUE as the lower bound. In Java this constant is the smallest positive non-zero value, not the most negative finite value, so the valid literal 0.0 is rejected.

Steps to Reproduce

1. Parse the selector expression a = 0.0.
2. Evaluate it with property a equal to 0.0.
3. Observe a runtime error stating that 0.0 is less than 4.9E-324.

What Did You Expect to See?

The parser should accept zero and other finite negative floating-point literals within the double range.

What Did You See Instead?

The parser throws while creating the zero constant.

Additional Context

The finite lower bound should be -Double.MAX_VALUE; positive and negative infinity remain outside the accepted range.

[RockteMQ-AI]

Issue Evaluation

Category: bug | Status: Confirmed

The reported issue has been verified against the current codebase (commit fd0c959).

Root Cause: ConstantExpression.createFloat() (line 61) uses Double.MIN_VALUE as the lower bound. In Java, Double.MIN_VALUE is 4.9E-324 — the smallest positive non-zero value — not the most negative finite value. Therefore 0.0 fails the check value < Double.MIN_VALUE and is rejected.

Impact: SQL selector expressions like a = 0.0 fail at runtime, preventing legitimate zero-value filtering.

Severity: high — breaks a fundamental use case (zero-value comparison in message selectors)

Suggested Fix: Change the lower bound to -Double.MAX_VALUE:

if (value < -Double.MAX_VALUE) {
    throw new RuntimeException(text + " is less than " + (-Double.MAX_VALUE));
}

An automated fix proposal will be generated. Reply /approve to proceed with PR generation.

---

Automated evaluation by RockteMQ-AI