iloveeyjafjalla opened a new issue, #11389: URL: https://github.com/apache/rocketmq/issues/11389
### Before Creating the Bug Report - [x] I found a bug, not just asking a question, which should be created in [GitHub Discussions](https://github.com/apache/rocketmq/discussions). - [x] I have searched the [GitHub Issues](https://github.com/apache/rocketmq/issues) and [GitHub Discussions](https://github.com/apache/rocketmq/discussions) of this repository and believe that this is not a duplicate. - [x] I have confirmed that this bug belongs to the current repository, not other repositories of RocketMQ. ### Runtime platform environment OS: any (broker module, POP consumer metrics) ### RocketMQ version branch: develop Git commit id: a7edeecfb (2026-10-13; the files are unchanged by that commit) ### JDK Version Compiler: Temurin 1.8.0_504 (target 1.8, same as CI) ### Describe the Bug A POP group whose retry topic does not exist yet records a consumer lag latency of about `-9.2e18` milliseconds. `ConsumerLagCalculator#getConsumerLagStats(group, topic, isPop)` uses `Long.MAX_VALUE` as the "no timestamp" sentinel and normalizes it at the end of the regular path: ```java long earliestUnconsumedTimestamp = Long.MAX_VALUE; ... if (earliestUnconsumedTimestamp < 0 || earliestUnconsumedTimestamp == Long.MAX_VALUE) { earliestUnconsumedTimestamp = 0L; } ``` but the early return for a missing topic skips that normalization: ```java if (group == null || topic == null) { return new Pair<>(total, earliestUnconsumedTimestamp); // still Long.MAX_VALUE } ``` The latency is derived from it: ```java public long getLagLatency() { return earliestUnconsumedTimestamp == 0 ? 0 : System.currentTimeMillis() - earliestUnconsumedTimestamp; } ``` so `now - Long.MAX_VALUE ≈ -9.223372035e18` is recorded as the value of `rocketmq_consumer_lag_latency`. Reachability with the default configuration (`enableLagAndDLqMetrics=true`): for a POP group, `calculate(info, recorder)` queries the retry series with `info.retryTopic`, and `processAllGroup` deliberately passes `null` for it when the retry topic config does not exist (`TopicConfigManager.selectTopicConfig(retryTopic) == null`). The broker creates a POP retry topic only lazily on the first nack (`PopReviveService.addRetryTopicIfNotExist`) or through an explicit admin call, so any POP group that has not retried a message yet hits this path. `getInFlightMsgStats` has the same early return feeding `rocketmq_consumer_queueing_latency`. Impact: the exported series carries a value around −292 million years, so every dashboard or alert that aggregates (mean/max/percentile) over those labels is destroyed by the outlier instead of reporting "no lag". ### Steps to Reproduce 1. Run a broker with the default `enableLagAndDLqMetrics=true` and a POP group whose retry topic ( `%RETRY%<group>`) has never been created. 2. Scrape the broker metrics and read `rocketmq_consumer_lag_latency{... is_retry="true"}`. 3. Its value is about `-9.223372035e18` (milliseconds) instead of `0`. ### Expected behavior An unknown topic reports no lag and no latency — `0`, exactly like the regular path normalizes an absent/negative timestamp. ### Actual behavior The sentinel escapes and the recorded latency is `now - Long.MAX_VALUE`. ### Additional context Fix: normalize the sentinel in the early return of both `getConsumerLagStats` and `getInFlightMsgStats`. -- 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]
