[studio][Bug] Malformed retry counters can abort Proxy message forwarding

[messere1]

Before Creating the Bug Report

• I found a bug, not just a question.
• I searched existing issues and pull requests for malformed reconsumeTimes, maxReconsumeTimes, and PROPERTY_RECONSUME_TIME handling.
• I confirmed the affected code belongs to this repository.

Describe the Bug

ProducerProcessor#buildSendMessageRequestHeader parses retry-message properties with Integer.valueOf:

• MessageConst.PROPERTY_RECONSUME_TIME
• MessageConst.PROPERTY_MAX_RECONSUME_TIMES

If either stored property is malformed, building the broker request header throws NumberFormatException and the Proxy send/retry path fails. The same method already tolerates a malformed born timestamp by falling back to the current time, but retry counters do not have equivalent defensive handling.

Expected Behavior

• Preserve the current behavior for valid retry counters.
• Treat a malformed reconsume-times value as the existing default of 0.
• Leave max-reconsume-times unset when its value is malformed.
• Keep clearing the internal retry properties from the message after handling them.
• Add focused tests proving malformed counters do not abort request-header construction.

Affected Area

RocketMQ Proxy producer/retry message processing used by RocketMQ Studio and gRPC/remoting operational flows.

Proposed Scope

Keep the change local to ProducerProcessor retry-counter parsing and its unit tests. Do not change public APIs or valid retry-message semantics.

[RockteMQ-AI]

Issue Evaluation

Category: type/bug | Module: module/proxy | Status: Confirmed

The reported issue has been verified against the current codebase (develop branch).

Root Cause: ProducerProcessor#buildSendMessageRequestHeader (lines 214, 220) calls Integer.valueOf() directly on PROPERTY_RECONSUME_TIME and PROPERTY_MAX_RECONSUME_TIMES without defensive error handling. If either property contains a non-numeric value, a NumberFormatException will abort the entire send/retry path.

Impact: Proxy message forwarding for retry messages can fail unexpectedly when upstream storage contains malformed retry counters. The same method already tolerates malformed born timestamps (line ~207) with a try-catch fallback, making this inconsistency notable.

Severity: Medium — affects retry message reliability in edge cases with corrupted metadata.

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

---

Automated evaluation by github-manager

[RockteMQ-AI]

Issue Evaluation

Category: bug | Status: Confirmed

The reported issue has been verified against the current codebase.

Root Cause: In ProducerProcessor.java (lines 214, 220), Integer.valueOf(reconsumeTimes) and Integer.valueOf(maxReconsumeTimes) are called without defensive parsing. If a message property contains a non-numeric value, a NumberFormatException propagates up and aborts the entire sendMessage request — affecting all messages in the batch, not just the malformed one.

Impact: Proxy message forwarding path. A single malformed retry property can block all messages in a send request.

Severity: Medium — availability impact on the Proxy forwarding path.

Suggested Fix: Wrap the Integer.valueOf calls with try-catch and fall back to a safe default (e.g., 0 for reconsumeTimes), similar to the defensive parsing already used for the born timestamp in the same class.

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

---

Automated evaluation by github-manager