[Bug] Proxy drops receipt handles when offline cleanup task submission is rejected

[Aias00]

Problem

DefaultReceiptHandleManager.clearGroup removes a receipt-handle group from receiptHandleGroupMap before submitting its cleanup task to the bounded returnHandleGroupWorkerService.

If the executor rejects the submission because its queue is full or it is shutting down, submit throws and the removed group is not restored. The Proxy then loses the handle state without sending the intended clear/renew request and cannot retry it on the next scheduled scan.

Expected behavior

A rejected cleanup submission must retain or restore the group so a later scheduled pass can retry cleanup. The rejection should be logged without leaking handle contents.

Scope

Handle RejectedExecutionException around clearGroup task submission and add a regression test that forces rejection.

[RockteMQ-AI]

Issue Evaluation

Category: bug | Status: Confirmed

The clearGroup receipt-handle loss on executor rejection has been verified against the current develop branch.

Root Cause: In DefaultReceiptHandleManager.java (line ~253-254), clearGroup removes the group from receiptHandleGroupMap before submitting the cleanup task. If returnHandleGroupWorkerService.submit() throws RejectedExecutionException (queue full or shutting down), the group is already removed and cannot be retried by the next scheduled scan.

Impact: The Proxy silently loses receipt-handle state without sending the intended clear/renew request. Affected handles remain in limbo until they expire naturally.

Severity: Medium — affects Proxy handle lifecycle under high load or shutdown scenarios.

Verified at: proxy/src/main/java/org/apache/rocketmq/proxy/service/receipt/DefaultReceiptHandleManager.java:249-255

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

---

Automated evaluation by RockteMQ-AI

[RockteMQ-AI]

Hi @Aias00, thanks for reporting this!

I've analyzed this issue against the codebase and can confirm this appears to be a real bug.

Root Cause: ** In DefaultReceiptHandleManager.clearGroup (line 253–254), receiptHandleGroupMap.remove(key) is called unconditionally before returnHandleGroupWorkerService.submit(...). If the executor rejects the submission (queue full or shutting down), a RejectedExecutionException is thrown and propagates up — the group has already been removed from the map but the cleanup task never ran. There is no catch block to restore the entry, so the handle state is permanently lost and the next scheduled scan cannot retry.
Affected Files: ** proxy/src/main/java/org/apache/rocketmq/proxy/service/receipt/DefaultReceiptHandleManager.java

Analysis: ** The returnHandleGroupWorkerService is bounded (queue sized by getRenewThreadPoolQueueCapacity()). Under load or during shutdown the queue can fill, causing submit() to throw RejectedExecutionException. Since the remove happens on line 253 before the submit on line 254, and no exception handling exists, the lost group will never be re-added via the putIfAbsent path in returnHandleGroup (which is only reached if the task actually runs). The proxy permanently loses the receipt handles for that group.

I'll prepare a fix spec and work on a PR. The community is welcome to provide feedback on the approach before implementation.

---

🤖 Automated issue analysis by github-manager

[RockteMQ-AI]

Issue Evaluation

Category: bug | Status: Confirmed

The issue is clear: clearGroup removes the handle group from the map before the cleanup task is submitted, and if the executor rejects the task, the group state is lost permanently.

Root Cause: Remove-before-submit pattern in DefaultReceiptHandleManager.clearGroup — no rollback on RejectedExecutionException.
Impact: Receipt handles are silently dropped, preventing proper message acknowledgment/ renewal. Over time this can cause messages to be redelivered unnecessarily or expire.
Severity: Medium

The proposed fix (retain/restore group on rejection, log without leaking handle contents, add regression test) is well-scoped.

---

Automated evaluation by github-manager