Galera test failure on galera.galera_2primary_replica

The test occasionally fails with result content mismatch

galera.galera_2primary_replica           w13 [ fail ]

        Test ended at 2026-06-09 22:41:31

CURRENT_TEST: galera.galera_2primary_replica

--- /data/buildbot/workers/prod/amd64-freebsd-14/build/mysql-test/suite/galera/r/galera_2primary_replica.result	2026-06-09 16:27:29.000000000 +0200

+++ /data/buildbot/workers/prod/amd64-freebsd-14/build/mysql-test/suite/galera/r/galera_2primary_replica.reject	2026-06-09 22:41:20.919491000 +0200

@@ -71,7 +71,7 @@

 1

 SELECT @@gtid_slave_pos,@@gtid_binlog_pos,@@gtid_current_pos;

 @@gtid_slave_pos	@@gtid_binlog_pos	@@gtid_current_pos

-3-3-1003,4-4-1003	3-3-1003,4-4-1003	3-3-1003,4-4-1003

+3-3-1002,4-4-1003	3-3-1003,4-4-1003	3-3-1002,4-4-1003

 connection primary1;

 drop table t1;

 connection primary2;

Result content mismatch

Root cause

When a write-set carrying a foreign-domain GTID is applied, the
applier (wsrep_apply_events) sees the write-set's leading GTID
event and immediately calls Wsrep_schema::store_gtid_event(),
which allocates a sub_id (rpl_slave_state::next_sub_id() — a
bare, mutex-protected ++counter with no relationship to the GTID's
seq_no), writes the mysql.gtid_slave_pos row, and publishes
the position into the shared, in-memory position hash
(update_state_hash()/update_nolock()) that backs
@@gtid_slave_pos and @@gtid_current_pos.

All three steps run at GTID-event-parse time — before the write-set's
own row changes are applied, and entirely outside wsrep's commit-order
critical section (the section bounded by commit_order_enter/commit_order_leave,
entered via wsrep_before_commit() and left via wsrep_ordered_commit()). Only the
write-set's real final commit goes through that section.

With more than one applier thread, each thread reaches this publish
step for its own write-set independently, with no ordering constraint
tying sub_id allocation across threads to true seqno order. The
reported position for a domain is computed by picking the hash entry
with the highest sub_id, not the highest seq_no — so if the
thread applying a higher-seqno write-set happens to publish before the
thread applying the immediately preceding lower-seqno write-set, the
lower seqno's entry (now holding the higher sub_id) overwrites the
reported position, producing a visible regression despite correct
underlying data