echooymxq opened a new issue, #10421: URL: https://github.com/apache/rocketmq/issues/10421
### 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 ubuntu ### RocketMQ version develop ### JDK Version 1.8 ### Describe the Bug In the timer message RocksDB store, when a delayed message is consumed, a `DELETE` record is written to remove it from RocksDB. Meanwhile, if the same message undergoes a Roll (CommitLog rotation), an `UPDATE `record is written to update its offset. The `DELETE_KEY_CACHE_FOR_TIMER` is used to prevent `UPDATE` from re-inserting an already-deleted key. the cache uses `byte[]` as its key type. Since `byte[].equals()` compares object references rather than content. ### Steps to Reproduce as describe. ### What Did You Expect to See? The UPDATE should be skipped since the key was already deleted, and no record should remain in RocksDB. ### What Did You See Instead? The UPDATE writes back the deleted record as a ghost record in RocksDB. ### Additional Context _No response_ -- 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]
