Before Creating the Bug Report

• I found a bug, not just asking a question, which should be created in GitHub Discussions.

• I have confirmed that this bug belongs to the current repository, not other repositories of RocketMQ.

• I have searched the GitHub Issues and GitHub Discussions of this repository and believe that this is not a duplicate.

Runtime platform environment

All platforms

RocketMQ version

develop

JDK Version

JDK 1.8

Describe the Bug

In ACL 2.0 authorization context builder, there is an incorrect consumer group extraction logic for retry topic in SEND_MESSAGE_V2 and SEND_BATCH_MESSAGE requests.

When processing retry topics (format: %RETRY%{ConsumerGroup}), the code incorrectly attempts to use field A (producerGroup) as the consumer group for permission validation, instead of extracting the consumer group from field B (retry topic name).

In SendMessageRequestHeaderV2:

• Field A = producerGroup
• Field B = topic (which could be a retry topic like %RETRY%ConsumerGroup)

The problematic code in DefaultAuthorizationContextBuilder.java:

case RequestCode.SEND_MESSAGE_V2:
case RequestCode.SEND_BATCH_MESSAGE:
    if (NamespaceUtil.isRetryTopic(fields.get(B))) {
        if (StringUtils.isNotBlank(fields.get(A))) {
            group = Resource.ofGroup(fields.get(A));  // Wrong: using producerGroup
        } else {
            group = Resource.ofGroup(fields.get(B));  // Correct: using retry topic
        }
        result.add(DefaultAuthorizationContext.of(subject, group, Action.SUB, sourceIp));
    }

Steps to Reproduce

Enable ACL 2.0 in RocketMQ
Send a message to a retry topic using SEND_MESSAGE_V2 or SEND_BATCH_MESSAGE request
The authorization check will use the producer group instead of the consumer group extracted from the retry topic name

What Did You Expect to See?

The consumer group should always be extracted from the retry topic name (field B) for authorization validation, regardless of whether field A (producerGroup) is present or not.

What Did You See Instead?

When field A (producerGroup) is not blank, it is incorrectly used as the consumer group for ACL permission validation, which causes authorization to check against the wrong resource.

Additional Context

No response