The test case is highly non-determinstic, run with a high value of repeat=N. It usually fails for me within several dozen attempts, but it can vary a lot on different machines and builds.
The compound block in the test case is irrelevant to the problem, it is used to get better concurrency within MTR. Instead, the same results can be achieved by running ALTER concurrently with a single UPDATE (send ALTER => run UPDATE => reap ALTER), but then it takes longer to reproduce.
The failure happens only when ALTER ends with ER_LOCK_WAIT_TIMEOUT. However, it doesn't always happen when ALTER ends with the timeout; apparently, a much thiner concurrency is involved, at least I couldn't serialize it neither on the SQL level nor via existing sync points in sql_table/sql_base.
So, the test creates/populates a table, then runs some DML on it and inplace ALTER .. ADD INDEX in parallel. ADD INDEX fails, the table seemingly doesn't get the index (neither show create nor I_S tables show it), but when the tablespace is imported in an identical table, it complains about an extra index in meta-data:
If we modify the test case slightly, removing this two lines:
– that is, instead of re-creating the table from scratch, we re-import the tablespace into the original one – it causes an assertion failure instead:
On 10.3 the same test case variation causes a different assertion failure: