I am not 100% sure it's a bug, but behavior is strange, so better to check if it's intended this way.
In the test case below,
- 1st connection (default) starts a transaction;
- it selects NEXTVAL from an InnoDB sequence;
- 2nd connection attempts to insert into the sequence and starts waiting;
- 1st connection, in turn, also attempts to insert into the sequence;
- 1st connection receives ER_LOCK_DEADLOCK;
- 2nd connection keeps waiting (till lock_wait_timeout is exceeded, unless 1st connection releases the sequence earlier).
Both before and after ER_LOCK_DEADLOCK processlist says that the 2nd connection is waiting for table metadata lock.
Two things seem strange to me.
First, that the deadlock occurs at all, it would appear that 1st connection should be in full possession of the sequence, if the other one is waiting for the lock.
Second, if deadlock is valid, why the 2nd transaction does not recognize it and keeps waiting.