There's no ordering between the prepare and commit/rollback messages, as the later are sent OOB.
With this in mind, the following transaction leak might happen:
Tx1 send prepare on nodes
1. the message reaches A and timeouts but hasn't yet been processed on B
2. The transaction originator reacts immediately to the timeout received from A without waiting the response from B and sends a rollback request
3. The rollback request is processed on A and B
4. The initial prepare is then processed on B
At this point we have an orphan transaction prepare on B.
Whilst this is not causing any inconsistencies, it keeps keys locked indefinitely and is a memory leak.
The solution would be to wait at 2 for all the prepare messages before sending the rollback.
Attached is a unit test to reproduce the issue.