False positive deadlock detected involving SELECT FOR SHARE / LOCK IN SHARE MODE

I have encountered a scenario where the deadlock detector incorrectly identifies a deadlock (False Positive). The scenario involves three transactions:

1. T1: Reads a range with LOCK IN SHARE MODE (IS/S locks).
2. T2: Updates a row outside T1's range (X lock).
3. T3: Issues an ALTER TABLE (Waiting for metadata locks).
4. T1: Attempts to delete the row held by T2.

Instead of T1 simply waiting for T2 to release the row lock, MySQL immediately throws ERROR 1213 (40001): Deadlock found.

However, if T1 uses FOR UPDATE instead of LOCK IN SHARE MODE in the initial SELECT, T1 waits correctly, and no deadlock is reported. This suggests the issue is specific to how shared locks interact with the pending DDL operation in the deadlock detection graph.

How To Repeat:
Prepare three separate sessions (Session 1, Session 2, Session 3).

Step 1: Initialization
use test;
drop table if exists table1;
create table table1 (pkId int primary key, colA int);
insert into table1 values (5, 100), (15, 200), (30, 100);

Step 2: Execution Flow
– txns
/* Session 1 */ begin;
/* Session 2 */ begin;
/* Session 1 */ select pkId, colA from table1 where pkId between 10 and 20 LOCK IN SHARE MODE;
– (Note: Also reproducible with `FOR SHARE`)
/* Session 2 */ update table1 set colA = 50 where pkId = 30;
– Next: Execute DDL. This will block waiting for T1 and T2 to finish (Metadata Lock).
/* Session 3 */ ALTER TABLE table1 ADD UNIQUE (colA);
/* Session 1 */ DELETE FROM table1 WHERE pkId = 30;

Observed Result:
Session 1 immediately fails with:
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

Expected Result:
Session 1 should block (Wait for Lock) because T2 holds the X-lock on pkId=30. There is no circular dependency between T1 and T2 regarding row locks. The pending DDL in T3 should not cause a false cycle in the wait graph.