qianye1001 opened a new issue, #11085: URL: https://github.com/apache/rocketmq/issues/11085
### Description The offset-reset integration tests have scheduling races and leave POP work running after test completion: - `OffsetResetIT` reads its pre-reset message count after sending reset requests. Replayed messages can already arrive before that read, so the test waits for more messages than the reset can produce. Its lag helper also compares a consumer offset from an RPC snapshot with a later live broker offset, which may have advanced legitimately. - `OffsetResetForPopIT` starts untracked executors whose loops run for 30 seconds even after the assertions and teardown. POP clients created directly by the test are never registered for cleanup. The loops swallow errors or print them continuously after the broker stops, obscuring actual failures. - These tests also enable `enablePopBufferMerge` after broker construction. If the POP KV service was constructed without a cache, the revive logging path dereferences the absent cache. Other POP operations already guard this case. ### Reproduction and evidence The Bazel run for #11081 failed `OffsetResetIT` and `OffsetResetForPopIT`. Its test stdout exceeded the 10 MiB output limit (approximately 17.9 MB and 1.52 GB), so the exact original assertions are unavailable. `OffsetResetIT` also failed in an earlier, unrelated CI run. On develop `37808b38c1`, both suites passed their 17 assertions locally, but leaked POP work produced 87,274,677 bytes of build/test output, including 32,819 stack frames from the background POP test lambda. This demonstrates that passing assertions do not imply clean teardown. A controlled scheduling experiment lets the reset replay complete before the test resumes post-reset bookkeeping: 2,400 original messages plus 300 replays give 2,700 deliveries, but the original test captures 2,700 as its baseline and waits for 3,000. The original times out; capturing the baseline before resetting passes under the same schedule. A focused test constructs `PopConsumerService` with buffering disabled, enables buffering, and calls `revive()`: it reproduces the null-cache exception at the logging statement. CI evidence: https://github.com/apache/rocketmq/actions/runs/34220792332 and https://github.com/apache/rocketmq/actions/runs/34201926158. -- 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]
