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

Ubuntu 20.04

RocketMQ version

develop

JDK Version

Oracle JDK 12

Describe the Bug

Misleading log in ConsumeQueue.recover(): offset and size always printed as 0

In org.apache.rocketmq.store.ConsumeQueue#recover(), when recovering a ConsumeQueue file, this log line is used:

log.info("recover current consume queue file over,  " + mappedFile.getFileName() + " " + offset + " " + size + " " + tagsCode);

However, this line always prints offset=0, size=0, and tagsCode=0 because it's triggered only when the condition offset < 0 || size <= 0 is met — i.e., invalid data.

This makes the log confusing, since it looks like the file ended at offset 0 with size 0, even if valid entries were processed.

Maybe the log should mention it's the end of valid data, or print the last valid offset/position instead.

ConsumeQueue.recover() 方法中的日志可能存在误导：offset 和 size 总是为 0

在 org.apache.rocketmq.store.ConsumeQueue#recover() 方法中，当遍历 ConsumeQueue 文件结束时，会打印如下日志：

log.info("recover current consume queue file over,  " + mappedFile.getFileName() + " " + offset + " " + size + " " + tagsCode);

但这条日志总是打印 offset=0、size=0，因为它只在 offset < 0 || size <= 0 的情况下触发（也就是数据无效时）。

这会让人误以为整个文件没有有效数据。建议改为打印“已恢复到文件末尾”之类的提示，或者输出最后一个有效位置，更具参考价值。

Steps to Reproduce

Just start it, logs show everything.

What Did You Expect to See?

I expected the log to reflect the actual end position of valid entries in the ConsumeQueue file

What Did You See Instead?

always 0 in the log line

Additional Context

Easy to fix.