[Bug] Overflowing relative timer delays can be treated as immediate

[yuluo-yx]

Before Creating the Bug Report

• I found a bug, not just a question.
• I searched open GitHub Issues and pull requests and found no duplicate.
• I confirmed that this bug belongs to Apache RocketMQ.

Runtime platform environment

macOS (Darwin), reproduced with an isolated local unit test.

RocketMQ version

Branch: develop
Git commit: fd0c959

JDK Version

Zulu OpenJDK 8 (8.94.0.17)

Describe the Bug

HookUtils converts relative timer delays using unchecked long multiplication and addition. A very large delay can overflow into a past timestamp, bypass the future-delay validation, and be accepted as an immediate message.

Steps to Reproduce

1. Create a timer message with TIMER_DELAY_SEC or TIMER_DELAY_MS set to Long.MAX_VALUE.
2. Pass it through HookUtils.handleScheduleMessage.
3. Observe that the overflowing delay is not rejected as an illegal timer message.

What Did You Expect to See?

A relative delay that cannot be represented as an absolute millisecond timestamp should return WHEEL_TIMER_MSG_ILLEGAL.

What Did You See Instead?

Overflow wraps the calculated delivery timestamp and the message can follow the immediate-message path.

Additional Context

Both seconds and milliseconds paths have deterministic unit reproductions in HookUtilsTest.

[RockteMQ-AI]

Issue Evaluation

Category: type/bug | Status: Confirmed

Root Cause: When computing the target delivery time for a relative timer delay, an overflowing addition (currentTime + delay) wraps around to a value in the past, which the timer wheel treats as an immediate delivery.
Impact: Timer/delayed messages — messages with large relative delays may be delivered immediately instead of at the intended future time, breaking delay message semantics.
Severity: high

---

Automated evaluation by github-manager-bot