[Bug] Transaction message functionality has severe data inconsistency #8158
Comments
SeanJi213
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
{{ message }}
SeanJi213
changed the title
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
MacOS 14.1
RocketMQ version
4.9.7
JDK Version
No response
Describe the Bug
Steps to Reproduce
For ISSUE 1:
The producer executes its local transaction for a relatively long time and does not return the state of its local transaction, long enough to let the check be triggered and return COMMIT before the producer does. In this case, there is a consumer subscribing the topic which we send transaction message to. So, as soon as the check method got a COMMIT, this message is consumed by the consumer. Right after check method returns COMMIT, the producer sends COMMIT to the broker, and the same message is consumed once again.
生产端控制台输出：
消费端消费到该条消息两次，重复消费：
For ISSUE 2:
The producer executes its local transaction for a relatively long time and does not return the state of its local transaction, long enough to let the check be triggered and return ROLLBACK first. In this case, there is also a consumer subscribing the topic which we send transaction message to. And right after the check method returns ROLLBACK, the producer finishes executing local transaction and sends a COMMIT to the broker, and this message can be consumed by the consumer somehow, which causes severe inconsistency.
生产端控制台输出：
消费端仍然消费到了本应被回滚的消息：
（针对这种情况，如果反之，回查先于生产端返回了COMMIT，在这之后生产端返回了本地事务状态-ROLLBACK，该条消息仍然会被消费到，消费时机为回查返回COMMIT时，造成不一致）
For ISSUE 3:
The producer executes its local transaction for a relatively long time and does not return the state of its local transaction, long enough for the check method to be triggered. In this scenario, the check method will return UNKNOW every time. And after a few checks, the producer finishes executing local transaction and sends a COMMIT to the broker. However, after this, check continues until it reaches the maximum check times, which is by default 15.
消费端能消费到该条消息：
For ISSUE 4:
If check is triggered and reaches its maximum check times and after this, the producer sends a COMMIT to the broker, this message, instead of being rollbacked as expected, can still be consumed by the consumer.
This is the message trace of this transaction message, indicating the message can be consumed after the number of check times reaches its maximum, which is by default 15.
What Did You Expect to See?
For scenario 1: The message should have been consumed only once.
For scenario 2: The message shouldn't have been consumed after being rollbacked.
For scenario 3: The check method should have stopped after the producer sends the final state of local transaction(commit/rollback).
For scenario 4: The message should have been rollbacked after the number of check times reaches its maximum, which is by default 15.
What Did You See Instead?
For scenario 1: The message is consumed twice.
For scenario 2: The message can still be consumed after being rollbacked first.
For scenario 3: The check method continues after the producer sends the final state of local transaction(commit/rollback).
For scenario 4: The message can still be consumed by sending COMMIT to the broker even after the number of check times reaches its maximum, which is by default 15.
Additional Context
No response
The text was updated successfully, but these errors were encountered: