ALTER SEQUENCE may end up in optimistic parallel slave binlog out-of-order

On optimistic parallel slave ALTER (Innodb) SEQUENCE passes the commit right too early to the next-to-commit transaction. It does so before its bilogging is done so that the following transaction may win race to binlog first and ALTER fail with an error like

Last_Error: Error 'An attempt was made to binlog GTID 0-1-100 which would create an out-of-order sequence number with existing GTID 0-1-101 and gtid strict mode is enabled' on query. Default database: 'test'. Query: 'alter sequence s1 restart with 1'

As a possible w/a, note ALTER has actually completed in the engine part (Innodb) not being able to binlog. The slave state is already past the ALTER's gtid so it's correct, nothing to do with gtid_slave_pos. If its absence in binlog is tolerable then the slave can be simply restarted. If the ALTER binlogging matters, then consider to re-execute ALTER, preserving its gitd course, from a slave local connection. After replaying from local slave connection ALTER (and its GTID) will end up logged out-of-order though (so gtid strict mode replication from this slave to elsewhere won't work out at its point).