galera_sr.GCF-1018B: --reap doesn't tolerate ER_NO_SUCH_TABLE under wsrep_sync_wait=0

The test galera_sr.GCF-1018B (mysql-test/suite/galera_sr/t/GCF-1018B.test) failed:

mysqltest: At line 34: query 'reap' failed with wrong errno ER_NO_SUCH_TABLE (1146): 'Table 'test.t1' doesn't exist', instead of (0)...

The test sets wsrep_sync_wait = 0 on both nodes (lines 8 and 14) before node_1 creates t1 and both nodes start a 500-iteration loop of concurrent INSERT/DELETE on t1 (lines 18-37). With wsrep_sync_wait = 0, node_2 does not wait for causality before running its DELETE FROM t1, so the first iteration can race node_1's CREATE TABLE t1 replicating over: node_2's DELETE can legitimately run before t1 exists there.

The --error list on the node_2 reap (line 33) only allows ER_LOCK_DEADLOCK, ER_DUP_ENTRY, ER_LOCK_WAIT_TIMEOUT, ER_QUERY_INTERRUPTED - it does not include ER_NO_SUCH_TABLE, even though the test's own design (no sync wait before the loop) makes that race possible on the first iteration.

Checked whether the immediately preceding test on the same worker (galera_sr_conflict) could be responsible: no. There is a full state transfer between the two tests (grastate.dat missing, fresh SST from node_1), so node_2 starts this test with no carried-over replication state. galera_sr_conflict itself ends cleanly (DROP TABLE t1, no kill). The race is inherent to this test's own wsrep_sync_wait=0 design and incomplete --error list.

A retry of the same test in the same run also failed with the same error, so this reproduces reliably enough under load.

Created via the jira-create skill.