ER_KEY_NOT_FOUND seems to become a generic marker for ONLINE ALTER TABLE.
The problem here is with an added AUTO_INCREMENT (SERIAL) for a field spec, whereas the initial values were 0:

CREATE TABLE t1 (b int) engine=InnoDB;

INSERT INTO t1 VALUES (0),(0);

connect  con1,localhost,root,,;

ALTER TABLE t1 MODIFY b SERIAL;

select * from t1;

b

1

2

DROP TABLE t1;

The autoinc value was silently applied under disabled NO_AUTO_VALUE_ON_ZERO mode.
So the value '0' from the online change could not be found.

here's the deterministic test:

--source include/have_innodb.inc

CREATE TABLE t1 (b int) engine=InnoDB;

INSERT INTO t1 VALUES (0);

--connect (con1,localhost,root,,)

set debug_sync= "alter_table_copy_end signal copy wait_for goon";

send ALTER TABLE t1 MODIFY b SERIAL;

--connection default

set debug_sync= "now wait_for copy";

DELETE FROM t1;

set debug_sync= "now signal goon";

--connection con1

--reap

# Cleanup

DROP TABLE t1;

let's try to disable ONLINE if AUTO_INC if forced on an existing column

serg I already wrote an algorithm that covers a good subset. I think I'd really like to avoid mentioning that something with AUTO_INC doesn't work in the article

You cannot disable NO_AUTO_VALUE_ON_ZERO, non-blocking alter must produce the same result as blocking.

Technically, you can do online when AUTO_INC is added if the old table had a PK and this PK isn't changed in the ALTER TABLE. But I think it's a very corner use case, normally AUTO_INC is PK.

serg Please review commits 11cc554...88a2ec

consider this example

create table t1 (a int, b int);

insert t1 values (1,NULL),(2,NULL),(3,NULL),(4,NULL);

update t1 set b=10 where a=2;

alter table t1 modify b int auto_increment, add key(b);

select * from t1 order by a,b;

drop table t1;

it prints

a       b

1       1

2       10

3       11

4       12

I don't understand how it could be even possible to do the above online.
If I recall correctly, conceptually online alter should produce the same result as if all concurrent updates were done before the alter.

Right, if we stick to taking effect after the changes applied, then this method won't work

But of course. A user does SELECT — sees the old table structure. Performs UPDATE, commits, runs SELECT again — sees the old table structure, with the updated content. There's no other way to interpret it, the UPDATE was applied to the old table structure, before the ALTER.

db2d411bc is obsolete, it seems, because d23555b19206 (MDEV-30984) rewrites it.

I've already commented on d23555b19206, so there's no need to review db2d411bc anymore.

Well, yes, it can be done so, almost. Thanks. the commit could be useful to understand the intentions at first place, but I can squash it