The summary might be not quite accurate looking from inside, but it describes the effect I observe. Please feel free to modify it if needed.
I have master=>slave setup with master_use_gtid=current_pos. The slave does not have log-slave-updates.
A test executes DML flow (1 thread only) on master, simultaneously checking gtid* values on slave every 10 seconds, and crashing and restarting the slave every 30 seconds.
To check the gtid* values, it uses the following query:
and prints the values like this:
Normally, I see either 3 equal values, as above, or
which I attributed to a delay at updating the variables.
However, every once in a while I see the following picture:
That is, mysql.gtid_slave_pos already had seq_no 14040 before server crash, but after restart it's back to 14039.
At the same time, I see no indication of the event 14040 being re-executed. So, it looks like no harm is done.
Transaction isolation level is default REPEATABLE-READ.
I find it bizarre, because to my understanding the table is supposed to be updated in the same transaction as the change the new GTID belongs to, so if I see the change, the transaction should be already committed; and then I don't understand how it can be rolled back after restart...
I can provide more information, including how to reproduce it with a stress test, or I can setup the test on perro, or modify the test in any manner, or do whatever it takes to debug it, but I'm also quite prepared to learn that it works as expected.
The effect is not related to two recent bugfixes, I observed it before as well.