[Bug] PopConsumerService changeInvisibilityDuration may lose CK record when visibilityTimeout collision

[qianye1001]

Before Creating the Bug Report

• I found a bug, not just asking a question, which should be created in GitHub Discussions.
• I have searched the GitHub Issues and GitHub Discussions of this repository and believe that this is not a duplicate.
• I have confirmed that this bug belongs to the current repository, not other repositories of RocketMQ.

Runtime platform environment

All platforms

RocketMQ version

branch: develop

Describe the Bug

In PopConsumerService.changeInvisibilityDuration, the RocksDB key is composed of visibilityTimeout(8) + groupId + topicId + queueId + offset, where visibilityTimeout = popTime + invisibleTime.

When changedPopTime + changedInvisibleTime == popTime + invisibleTime (i.e., the new CK has the same visibilityTimeout as the old one), both ckRecord and ackRecord produce the same RocksDB key.

The current code flow:

1. writeRecords(ckRecord) — writes new CK (overwrites old record at same key)
2. deleteRecords(ackRecord) — deletes using the same key, which removes the newly written CK

This results in the message never being retried.

Steps to Reproduce

1. Pop a message with popTime=1000, invisibleTime=5000 (visibilityTimeout=6000)
2. Call changeInvisibilityDuration with changedPopTime=3000, changedInvisibleTime=3000 (visibilityTimeout=6000)
3. The new CK and old CK have the same RocksDB key
4. After writeRecords + deleteRecords, the CK record is lost

What Did You Expect to See?

The new CK record should persist in RocksDB so the message can be retried after the new invisibility timeout.

What Did You See Instead?

The new CK record is deleted because the delete operation uses the same key as the write, causing the message to never be retried.