[ISSUE #10739] Complete proxy futures when processor executors reject tasks

[ai-yang]

Which Issue(s) This PR Fixes

• Fixes [Bug] Proxy processor futures can remain pending when completion tasks are rejected #10739

Brief Description

FutureUtils.appendNextFuture now retains the stage returned by whenCompleteAsync and propagates completion-task scheduling failures to the future returned to the caller.

The Proxy producer and consumer processor executors now use an explicit AbortPolicy. This is required because the shared default DiscardOldestPolicy can silently discard completion tasks during shutdown or saturation, leaving no rejection for FutureUtils to propagate. Other RocketMQ thread pools keep their existing rejection behavior.

Together, these changes ensure that Proxy request futures reach an exceptional terminal state instead of remaining pending when processor completion work is rejected.

How Did You Test This Change?

• On the unmodified JDK 8 baseline, the helper-level and real producer-pool regressions each failed at the expected pending-future assertion in 5/5 runs.
• The fixed regressions explicitly assert RejectedExecutionException and cover both Proxy producer and consumer pools. Twenty isolated JUnit processes passed all 6 tests each (120/120).
• Final full JDK 8 proxy -am test reactor: all 11 modules succeeded in 33:50; Broker ran 752 tests (0 failures, 0 errors, 4 skipped) and Proxy ran 304 tests (0 failures, 0 errors, 3 skipped).
• Checkstyle and SpotBugs passed throughout the full reactor.
• Explicit JDK 8 common,proxy Maven validate: both modules passed with 0 Checkstyle violations.
• git diff --check: passed.

[RockteMQ-AI]

Findings

• [Info] FutureUtils.java:27-34 — The fix is correct. completionFuture.whenComplete(...) runs synchronously in the completing thread (not submitted to the executor), so it reliably catches RejectedExecutionException without needing another executor. Good design.

• [Info] DefaultMessagingProcessor.java:89,98 — Switching from the default DiscardOldestPolicy to AbortPolicy is the right call here. Under high load or shutdown, tasks that were previously silently discarded will now surface as RejectedExecutionException, which FutureUtils can properly propagate. This is a behavioral change, but it converts silent data loss into explicit failure — the correct tradeoff for a messaging system.

• [Info] FutureUtilsTest.java — Test coverage is solid. The shut-down executor pattern reliably reproduces the rejection scenario, and asserting CompletionException wrapping RejectedExecutionException validates the full propagation chain.

• [Info] DefaultMessagingProcessorTest.java — Good integration-level test that verifies the real executor chain propagates rejections through the future.

Suggestions

• Minor: Consider whether other thread pools in the Proxy module that also use appendNextFuture (or similar future-chaining patterns) might need the same AbortPolicy treatment. A quick audit of ThreadPoolMonitor.createAndMonitor call sites in the proxy module could reveal similar latent issues.

Verdict

Well-structured bug fix that addresses both the symptom (pending futures) and root cause (silent task discarding). The two-level approach ensures robustness even if one layer is misconfigured.

---

Automated review by github-manager-bot