[ISSUE #10748] Fix unsupported ProxyChannel command completion

[ai-yang]

Which Issue(s) This PR Fixes

• Fixes [Bug] ProxyChannel leaves unsupported RemotingCommand writes permanently pending #10748

Brief Description

ProxyChannel.writeAndFlush() created an incomplete processFuture before dispatching a RemotingCommand, but the default switch branch only broke out of the switch. No producer remained that could complete the future, so the returned channel future stayed pending forever.

This change:

• completes the existing processing future exceptionally for unsupported remoting command codes;
• includes the unsupported request code in the failure for diagnosis;
• keeps relay services untouched for commands that have no supported dispatch path;
• reports that the command was not delivered instead of returning success or waiting for a response that cannot arrive.

How Did You Test This Change?

• Unmodified develop: the deterministic strengthened regression failed in 5/5 isolated JDK 8 Maven processes.
• Fixed regression: 20 isolated Maven/JVM processes at 1/1 each (20/20 total).
• Complete proxy -am reactor: all 11 modules passed with 0 failures and 0 errors.
• Project Checkstyle: 0 violations.
• SpotBugs: 0 bug instances and 0 errors.
• Maven validate: passed.
• git diff --check: passed.

Compatibility and Failure Semantics

Supported RemotingCommand branches and non-RemotingCommand messages are unchanged. Only the unsupported request-code branch changes: instead of leaving the returned ChannelFuture pending forever, it now completes exceptionally and does not invoke a relay service, allowing callers to observe that the command was not delivered.

[RockteMQ-AI]

Review by github-manager-bot

Summary

Fixes a resource leak where unsupported remoting commands in ProxyChannel.writeAndFlush would leave the processFuture hanging indefinitely by completing it with UnsupportedOperationException in the default switch case.

Findings

• [Info] ProxyChannel.java:114 — Adding processFuture.completeExceptionally() in the default case is the correct fix. Previously, callers waiting on the future for an unsupported command code would block forever, potentially leaking threads and memory.
• [Info] The exception message includes the unsupported command code, which aids debugging.
• [Info] ProxyChannelTest.java — Test verifies that the future completes with failure, the cause is UnsupportedOperationException, and the message contains the command code. Also verifies no interaction with the relay service for unsupported commands.

Suggestions

• None. Simple, correct fix with good test coverage.

---

Automated review by github-manager-bot

[RockteMQ-AI]

Summary

Defensive fix with proper validation and test coverage. LGTM.

---

Automated review by github-manager-bot

[ai-yang]

@lizhimins @lollipopjin, could you please take a human review when convenient? This is a focused ProxyChannel completion fix: unsupported remoting command codes now fail the returned future instead of leaving it pending, while supported branches remain unchanged. The complete 11-module reactor, Checkstyle, and SpotBugs pass. The remaining GitHub Actions runs are currently awaiting maintainer approval.

[ai-yang]

Refreshed this PR against the latest develop (e348efa66b08eb645ee123706ea6492fa9a3ad35, RocketMQ 5.5.1).

• refreshed head: 84147bcdc (one signed-off commit);
• complete ProxyChannelTest: 2/2 passed;
• all 11 modules in the targeted proxy -am reactor completed successfully, including Checkstyle and SpotBugs;
• git diff --check passed.

The force-push has retriggered the full CI matrix.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 49.29%. Comparing base (1a50c6e) to head (354ba02).

Additional details and impacted files

@@              Coverage Diff              @@
##             develop   #10752      +/-   ##
=============================================
- Coverage      49.36%   49.29%   -0.07%     
+ Complexity     14230    14207      -23     
=============================================
  Files           1390     1390              
  Lines         103123   103125       +2     
  Branches       13484    13484              
=============================================
- Hits           50904    50835      -69     
- Misses         46061    46111      +50     
- Partials        6158     6179      +21     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ai-yang]

CI triage update:

The only failing check is the Windows Maven job, where TimerMessageStoreTest#testTimerFlowControl failed. This PR only changes ProxyChannel and ProxyChannelTest; the affected test passes 2/2, and the other 9 checks passed. I found no direct overlap with the timer-store failure, so no PR code change is indicated by this result.

A maintainer rerun of the failed workflow would be appreciated.

[ai-yang]

Refreshed onto develop at 1a50c6e4e and pushed signed-off commit 354ba0278. The unsupported-command fix is unchanged (git range-diff reports the patch as equivalent).

Latest clean verification on JDK 8:

git submodule update --init --depth 1 -- rocketmq-apis
mvn -pl proxy -am -DskipITs -Dtest=ProxyChannelTest \
  -Dsurefire.failIfNoSpecifiedTests=false clean test

ProxyChannelTest: 2/2 passed, 0 failures/errors/skips. All 12 reactor modules succeeded, including the new protocol module. Checkstyle and SpotBugs passed for project code; generated protocol code follows upstream's configured exclusions. git diff --check passed.

This starts a new full CI matrix on the current base. The previous Windows TimerMessageStoreTest failure remains historical evidence and is not assumed fixed until the new job completes.

@xdkxlk @lizhimins, could you take a human review of the unsupported-code failure semantics when convenient?