If both causal_reads=universal and transaction_replay=true are in use and a read-only transaction started with START TRANSACTION READ ONLY is interrupted during the GTID probing phase, it is possible that the query for which the GTID probe was being done is not sent after the transaction replay is complete. The transaction replay ends up being started twice if the server where the query would be routed after the GTID probing was done ends up failing before the server where the GTID probing is being done. With the right timing, two transaction replays end up being done which usually causes two START TRANSACTION statements to be sent.

So far this has only manifested as a failure of the mxs3663_universal_causal_reads test case and would only happen if two servers failed simultaneously.