fix(broker): tolerate non-numeric TIMER_OUT_MS when attaching recall handle

[zjncs]

Motivation

attachRecallHandle parsed the client-visible TIMER_OUT_MS property with Long.parseLong before doResponse in the async send path. A message carrying a non-numeric value threw NumberFormatException, so the send response was never written and the client hung until its own timeout.

Modifications

Parse with NumberUtils.toLong and skip building the recall handle when the value is not a non-negative number, mirroring the guard already used in RecallMessageProcessor.

Verification

Fail-before (new test, run against the unpatched code):

SendMessageProcessorTest#testAttachRecallHandle_invalidTimestamp
java.lang.NumberFormatException: For input string: "not-a-timestamp"
  at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:67)
  (thrown from SendMessageProcessor.attachRecallHandle before the response was written)

Pass-after:

Tests run: 17, Failures: 0, Errors: 0, Skipped: 0 -- SendMessageProcessorTest

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[RockteMQ-AI]

Summary

Fix attachRecallHandle to tolerate non-numeric TIMER_OUT_MS values using NumberUtils.toLong with a sentinel, instead of throwing NumberFormatException. Silently skips the recall handle attachment for invalid timestamps.

LGTM — robust input validation.

---

Automated review by github-manager-bot