[ISSUE #10421] Fix Timer message RocksDB cache key using ByteBuffer

[itxaiohanglover]

What is the purpose of the change

Fixes #10421

In the timer message RocksDB store, DELETE_KEY_CACHE_FOR_TIMER is used to prevent an UPDATE record from re-inserting an already-deleted key (which would leave a ghost record in RocksDB).

However, the cache uses byte[] as its key type. Since byte[].equals() compares object references rather than content, and TimerRocksDBRecord.getKeyBytes() returns a new byte array each time, cache.getIfPresent(keyBytes) always returns null even when the same key content was previously put. As a result, the UPDATE path always writes the record back, producing ghost records.

Brief changelog

In MessageRocksDBStorage.java:

• Change DELETE_KEY_CACHE_FOR_TIMER cache key type from Cache<byte[], byte[]> to Cache<ByteBuffer, byte[]>. ByteBuffer implements content-based equals()/hashCode(), so cache lookups match on key content rather than array identity.
• Wrap keys with ByteBuffer.wrap(keyBytes) in both cache.put(...) and cache.getIfPresent(...) calls.

Verifying this change

• The DELETE branch now correctly stores a ByteBuffer-wrapped key, and the UPDATE branch correctly retrieves it by content, so already-deleted keys are skipped as intended.
• java.nio.ByteBuffer is already imported in the file, so no new imports are required.

Follow this checklist to request a review from a maintainer:

• Make sure there is a Github issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a Github issue. Your pull request should address just this issue, without pulling in other changes.
• Each commit in the pull request should have a meaningful subject line and body.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Check the style with ./mvnw -T 2C clean checkstyle:check.
• Run ./mvnw -T 2C clean test -Dtest=... to make sure unit tests pass.

[RockteMQ-AI]

LGTM

[RockteMQ-AI]

Review by github-manager-bot

Summary

Fixes a cache key correctness bug in MessageRocksDBStorage where DELETE_KEY_CACHE_FOR_TIMER used byte[] as the key type. Since byte[].equals() compares object identity rather than content, the cache lookup in the UPDATE path always returned null, causing ghost records to persist in RocksDB.

Findings

• [Positive] Correct root-cause fix — ByteBuffer.wrap() provides content-based equals()/hashCode(), which is the standard Java pattern for using byte arrays as map/cache keys.
• [Positive] Minimal change surface (3 lines in 1 file), no public API impact, no new dependencies.
• [Info] ByteBuffer.wrap() does not copy the underlying array — it creates a lightweight view, so there is negligible allocation overhead compared to the original byte[] key approach.
• [Info] Consider adding a unit test that verifies the DELETE-then-UPDATE path correctly skips re-insertion, to prevent regression. The test could perform a DELETE followed by an UPDATE with the same key content (but different byte[] instances), and assert the key is not re-inserted.

Verdict

LGTM. Clean fix for a real correctness bug. Approved.

---

Automated review by github-manager-bot