zjncs opened a new pull request, #11100:
URL: https://github.com/apache/rocketmq/pull/11100
### Motivation
`ConsumeQueue.estimateMessageCount` dereferences the ext unit
unconditionally:
```java
ConsumeQueueExt.CqExtUnit ext = null;
if (isExtWriteEnable()) {
ext = consumeQueueExt.get(tagCode);
tagCode = ext.getTagsCode(); // NPE when get() returns null
}
```
The stored `tagsCode` can legitimately be a raw (positive) value rather than
an ext address:
- entries written while the ext was disabled and the config was enabled
later, or
- entries persisted by the *save-tagsCode-only* fallback in
`putMessagePositionInfoWrapper` when `consumeQueueExt.put` fails (logged as
"Save consume queue extend fail, So just save tagsCode").
For a raw code `ConsumeQueueExt.get` returns `null` (it rejects non-ext
addresses), so `estimateMessageCount` throws an NPE. This path is live in
production: `DefaultMessageStore.estimateMessageCount` →
`ConsumerLagCalculator` (broker consumer-lag metrics with a filter).
`MessageFilter.isMatchedByConsumeQueue` already accepts a null ext unit
("message is before consumer"), so only this caller assumes non-null.
### Modifications
- Null-guard the ext unit: keep the raw `tagCode` when `get` returns `null`
and pass the null ext to the filter, matching how the rest of the code treats a
missing ext.
### Verification
Fail-before (new test on unpatched code):
```
ConsumeQueueTest.testEstimateMessageCountWhenExtUnitMissing:500 » NullPointer
Cannot invoke "ConsumeQueueExt.getTagsCode()" because "ext" is null
```
The test writes one entry with the ext disabled (raw tagsCode persisted),
re-enables the ext, then estimates the count — exactly the mixed-content state
described above.
Pass-after:
```
mvn -pl store test
-Dtest='ConsumeQueueTest#testEstimateMessageCountWhenExtUnitMissing+testCorrectMinOffset'
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
