The transaction_replay feature currently relies on the user knowing how to write SQL statements that do not cause problems when being replayed. The limitations section of the readwritesplit documentation explains that there are some statements that cannot be replayed in a manner that guarantees that the result is the same. This includes but is not limited to:

• A SELECT that's done without SELECT ... FOR UPDATE followed by an UPDATE of the selected rows
• INSERT of rows into a table that does not have an auto-increment primary key
• A "blind update" of one or more rows that doesn't read the values, e.g. UPDATE t SET c = c + 1 WHERE id = 123
• A similar "blind delete" that doesn't read the value, e.g. DELETE FROM t LIMIT 100

Some of these could be detected by readwritesplit and when seen, the replaying of the transaction could be prevented.

An additional improvement would be to not replay individual statements that aren't SELECTs executed outside of a transaction when autocommit is enabled. Currently the behavior of delayed_retry is to retry the query which has a risk of duplicate insertion if the query ends up being committed but the connection to the server is lost before readwritesplit reads the OK response.