Possible scenario:

• write is sent with tx_num=1, and fails
• another operation is sent, tx_num is advanced to 2
• original write is retried, using tx_num=1 which fails

Environment is likely multithreaded puma on heroku.

Could be due to driver clients being reused across threads, and then different threads snatching the same session object out of the session pool between the original write and the write retry. In which case we might need to mark a session "in use/holding" if we are deciding to retry a write, or maybe to not ever reuse sessions after they had retry-eligible errors happen on them.