Node aborts via uncaught gu::Exception from allowlist check on rejoin

The test galera.galera_wsrep_schema_detached crashed node_2 (mysqld.2).

Version: 11.8.10-MariaDB-log, source revision 0db6d3841fe324d62f0b932efbcd0f3623c86b34, Galera 26.4.28(r4e767fc7), aarch64 build.

The test (mysql-test/suite/galera/t/galera_wsrep_schema_detached.test) runs this sequence on node_2:

• line 26: SET GLOBAL WSREP_ON=0 - node_2 detaches from the cluster (mysqld.2.err: "Stop replication by 12").
• line 27-30: confirms mysql.wsrep_allowlist is empty (EXPECT_0).
• line 32: INSERT INTO mysql.wsrep_allowlist (ip) VALUES (0) - the table now holds one row that matches no real peer address.
• line 33: SET GLOBAL wsrep_cluster_address = @wsrep_cluster_address_orig - this reconnects node_2 to the cluster (mysqld.2.err: "Start replication"), while the bogus row from line 32 is still present.
• line 35: DELETE FROM mysql.wsrep_allowlist - runs only after the reconnect, too late.

The reconnect at line 33 is where the crash happens, right after "Start replication" / "Server status change connected -> joiner":

terminate called after throwing an instance of 'gu::Exception'

  what():  Connection not allowed, IP not found in allowlist.: Success: System error: 0 (Success)

	 at ./galerautils/src/gu_asio_stream_react.cpp:throw_sync_op_error():190

261108 19:49:58 [ERROR] mariadbd got signal 6 ;

With the bogus row as the only allowlist entry, the check switches to strict mode and rejects the real peer's address. The resulting gu::Exception is not caught anywhere in the call path, so it reaches std::terminate() and the process aborts (SIGABRT), instead of the rejected connection being handled as a normal error.

This happens before the test's own include/kill_galera.inc / include/start_mysqld.inc restart, which comes later in the test (line 38/48) and is unrelated to the crash.

The preceding test in the same run, galera_wsrep_new_cluster, leaves the same mariadbd process running into this test (no restart in between, confirmed from mysqld.2.err), but does not contribute to the crash: mysql.wsrep_allowlist is confirmed empty before this test's own insert, so there is no carried-over state. The crash is fully explained by this test's own statement ordering.

A retry of the same test in the same run passed, so this does not reproduce on every run (likely timing between the allowlist reload and the reconnect).

Created via the jira-create skill.