Ayush0612005 commented on issue #11304: URL: https://github.com/apache/rocketmq/issues/11304#issuecomment-5956180066
Hi, I looked into this and I think the root cause may differ from the one described. LiteConsumerLagCalculator always emits isRetry=false, so it can't produce a duplicate is_retry="true" series. Also, 5.3.3 doesn't have the Lite calculator at all. In 5.3.3, when enableNotifyBeforePopCalculateLag is on and a pop request is pending, calculateLag passes lagRecorder into an async PopCommandCallback. That callback records into the OTel measurement later, from another thread, outside the collection callback. Those late writes can collide with the synchronous ones and produce duplicate label sets. [apache/rocketmq#9873](https://github.com/apache/rocketmq/pull/9873) (released in 5.4.0) changed this to a CompletableFuture-based approach, so could you check whether the exception still reproduces on 5.4.0+? While reading the current develop code, I also noticed a related issue. The async path calls calculate(info, future::complete), but for Pop groups calculate() invokes the recorder twice (normal lag, then retry lag). CompletableFuture.complete only keeps the first value, so the is_retry=true lag result is silently dropped whenever a pop request is pending. I'd like to work on a fix: collect all results from calculate() in the async path, not just the first, plus a unit test covering Pop groups. Could this be assigned to me? -- 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]
