f1amingo opened a new issue, #10549: URL: https://github.com/apache/rocketmq/issues/10549
### 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: Linux / macOS ### RocketMQ version branch: develop ### JDK Version Compiler: Oracle JDK 11 ### Describe the Bug Three related bugs in lite topic offset reset: 1. **Memory leak in `resetOffsetTable`**: `removeResetOffset()` removes a queueId from the inner map but never cleans up the map entry when it becomes empty. Over time, `resetOffsetTable` accumulates stale keys with empty maps. 2. **FIFO block bypass missing on reset**: When `useServerSideResetOffset` is enabled and a reset offset is pending for a lite topic, `PopLiteMessageProcessor.isFifoBlocked()` still delegates to `consumerOrderInfoManager.checkBlock()`, causing consumption to be incorrectly blocked after a reset. 3. **Reset to offset 0 silently skipped**: `ResetOffsetByTimeCommand` uses `resetOffset > 0` to guard the actual reset call, so resetting to offset 0 (a valid offset) is silently ignored. ### Steps to Reproduce 1. **Memory leak**: Assign reset offsets for multiple queueIds of the same topic+group, remove them one by one via `removeResetOffset`, and observe that `resetOffsetTable` still contains the key with an empty inner map. 2. **FIFO block**: Set `useServerSideResetOffset=true`, assign a reset offset for a lite topic, then call `isFifoBlocked` — it returns `true` (blocked) instead of `false`. 3. **Offset 0**: Use `mqadmin resetOffsetByTimestamp` to reset a consumer to offset 0. The command prints the offset but does not execute the reset. ### What Did You Expect to See? 1. `resetOffsetTable` entries are fully removed when the inner map becomes empty. 2. `isFifoBlocked` returns `false` when a reset offset is pending, allowing immediate consumption from the reset position. 3. Resetting to offset 0 is executed normally. ### What Did You See Instead? 1. Stale empty-map entries remain in `resetOffsetTable`. 2. FIFO block check still blocks consumption after a reset. 3. Reset to offset 0 is silently skipped. ### Additional Context A new `eraseResetOffset(topic, group, queueId)` method is introduced for precise cleanup, and is called during lite topic removal in `AbstractLiteLifecycleManager` to prevent orphaned reset entries. -- 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]
