[Bug] LMQ name contains file separator would create illegal CQ path, which could make broker restart failed at check CQ file.

[humkum]

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

CentOS 7

RocketMQ version

5.0

JDK Version

1.8

Describe the Bug

If LMQ name contains file separator, for example "%LMQ%lmq_test/1", which would generate a CQ path,like follows:

When restart the broker, the broker would stop at check:

2023-05-12 16:03:56 WARN main - /home/work/hdd1/test/broker/30911/consumequeue/%LMQ%lmq_test/1/0        4096 length not matched message store config value, please check it manually

Steps to Reproduce

1. Message add UserProperty, and send these messages to broker

message.putUserProperty("INNER_MULTI_DISPATCH", "%LMQ%lmq_test/1");

2. Wait broker reput cq index.
3. Restart the broker

What Did You Expect to See?

Broker restart success.

What Did You See Instead?

Broker start failed because of check CQ file failed.

2023-03-16 16:03:56 WARN main - /home/work/hdd1/test/broker/30911/consumequeue/%LMQ%lmq_test/1/0        4096 length not matched message store config value, please check it manually

Additional Context

No response

[DongyuanPan]

This feature is used in rocketmq-mqtt. There are multi-level topics in mqtt. When using it, the multi-level topics of mqtt are escaped, and the / character is escaped into %. There is currently no interception/incoming on the broker side of this place. Do you have any scenarios where you directly use the INNER_MULTI_DISPATCH feature of LMQ?

[humkum]

This feature is used in rocketmq-mqtt. There are multi-level topics in mqtt. When using it, the multi-level topics of mqtt are escaped, and the / character is escaped into %. There is currently no interception/incoming on the broker side of this place. Do you have any scenarios where you directly use the INNER_MULTI_DISPATCH feature of LMQ?

Not another scenarios yet, we found this case just in test phase.