This is the last ticket to solve deadlocks in XA parallel replication.

After MDEV-26682 and MDEV-33454 there is only one possibility for a parallel replication applier thread to wait for a prepared XA transaction — if it'll step on a row that was modified by the prepared XA transaction.

But the very fact that this — later — transaction is being executed means, that on the master it did not step on that row. Probably, because of a different execution plan. This means that on the slave it does not have to wait for XA COMMIT, this row won't be part of the write set, it'll be rejected by the WHERE clause anyway. The applier can simply ignore this row, pretend that it doesn't exists, and move on.

That is, in the replication applier thread InnoDB does not need to wait on rows, modified by a prepared transaction.

Note: there is a special case here, if a binlog contains XA PREPARE ... XA COMMIT (or ROLLBACK) ... some other transaction — that this other transaction can start getting applied before XA COMMIT/ROLLBACK. In that case it has to wait on the row lock, because it would be a row it could had seen on the master. This is why rows can only be skipped if no XA ROLLBACK or XA COMMIT has already been read from the relay log and scheduled for execution.