[Bug] Fix the issue of missing bornTime in POP requests when broker ACL is enabled

[dingshuangxi888]

Before Creating the Bug Report

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

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

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

Runtime platform environment

Messages cannot be consumed by gRPC client when ACL is enabled on both proxy and broker in a storage-compute separation architecture.
The broker's pop message interface throws the error 'the broker[%s] pop message is timeout too much'.

RocketMQ version

5.3.2, 5.3.3, develop

JDK Version

java11

Describe the Bug

Messages cannot be consumed by gRPC client when ACL 2.0 is enabled on both proxy and broker in a storage-compute separation architecture.
The broker's pop message interface throws the error 'the broker[%s] pop message is timeout too much'.

Steps to Reproduce

1. deploy proxy and broker with ACL 2.0 enabled.
2. use grpc java client to consume message.

What Did You Expect to See?

The grpc client will consume messages when the topic has messages.

What Did You See Instead?

Threse is no message consumed.

Additional Context

No response

[aonexyz]

Thanks for sharing the detailed reproduction steps this really helps in narrowing down the issue.

From the behavior you described, it seems the problem is related to ACL 2.0 authentication logic on the proxy and broker causing the gRPC consumer request to stall. When ACL is enabled on both sides in a storage-compute separation setup, the broker’s POP interface timing out usually indicates that:

1. The gRPC request is reaching the proxy correctly,
2. But the proxy → broker POP request is blocked or rejected because of ACL verification,
3. Leading to the broker returning pop message is timeout too much.

A few things you may want to check:

1. Validate ACL Synchronization

Make sure the proxy and broker have consistent ACL configuration (accessKey, secretKey, permission levels). Even small mismatches can cause silent authentication failures.

2. Check POP Processing Logs

On the broker:

• enable TRACE or DEBUG for ACL and POP modules
• check if the POP request is marked as unauthorized or rejected internally

3. Confirm Proxy - Broker Authentication

In storage-compute separation, POP flows depend heavily on the proxy passing the correct credentials to the broker. If the proxy is not forwarding ACL metadata as expected, the broker will delay until timeout.

4. Try Consuming Without ACL

If disabling ACL makes the POP flow work normally, it confirms the issue is ACL-related and not a POP scheduling problem.

5. Test With Non-gRPC Client

Try consuming using a classic Java client (non-gRPC).
If that works, then the bug likely exists specifically in gRPC ACL metadata handling.

6. This Might Be a Real Bug

Given that the issue appears in versions 5.3.2, 5.3.3, and develop, it’s possible that:

• the gRPC consumer does not pass ACL attributes correctly, or
• the proxy’s ACL interceptor is not forwarding metadata to the broker.

So your report is valid and reproducible.

If needed, you can also share:

• proxy logs (INFO + DEBUG for ACL)
• broker logs around POP timeout
• your ACL config snippet (with keys masked)

This will help maintainers pinpoint whether it's an authentication forwarding bug or a POP request validation issue.

Thanks again for reporting this looks like something that needs investigation.