rebase auto_increment in multi object ALTER TABLE does not update the same TiDB node's cached auto id.

[mjonss]

Bug Report

Please answer these questions before submitting your issue. Thanks!

1. Minimal reproduce step (Required)

create table t (a int not null auto_increment primary key, b int) auto_id_cache 100;
insert into t (b) values (1);
alter table t add column c int, auto_increment 200;
insert into t (b) values (2); -- I would expect this to generate at least a = 200!
select * from t;
show create table t\G

2. What did you expect to see? (Required)

That the insert after the AUTO_INCREMENT was altered to 200 to be at least 200, not continue as nothing happened!

3. What did you see instead (Required)

tidb> create table t (a int not null auto_increment primary key, b int) auto_id_cache 100;
Query OK, 0 rows affected (0.09 sec)

tidb> insert into t (b) values (1);
Query OK, 1 row affected (0.01 sec)

tidb> alter table t add column c int, auto_increment 200;
Query OK, 0 rows affected (0.34 sec)

tidb> insert into t (b) values (2);
Query OK, 1 row affected (0.00 sec)

tidb> select * from t;
+---+------+------+
| a | b    | c    |
+---+------+------+
| 1 |    1 | NULL |
| 2 |    2 | NULL |
+---+------+------+
2 rows in set (0.01 sec)

tidb> show create table t\G
*************************** 1. row ***************************
       Table: t
Create Table: CREATE TABLE `t` (
  `a` int(11) NOT NULL AUTO_INCREMENT,
  `b` int(11) DEFAULT NULL,
  `c` int(11) DEFAULT NULL,
  PRIMARY KEY (`a`) /*T![clustered_index] CLUSTERED */
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin AUTO_INCREMENT=200 /*T![auto_id_cache] AUTO_ID_CACHE=100 */
1 row in set (0.01 sec)

4. What is your TiDB version? (Required)

tidb_version(): Release Version: v7.5.0-alpha
Edition: Community
Git Commit Hash: 012869faded0a84e031b018e5a03c0f7d1ff021b
Git Branch: heads/refs/tags/v7.5.0-alpha
UTC Build Time: 2023-10-20 14:46:30
GoVersion: go1.21.3
Race Enabled: false
Check Table Before Drop: false
Store: tikv

[mjonss]

Looks like only the first sub job will create a new schema diff. The following ones will skip it due to proxyJob.MultiSchemaInfo.SkipVersion = true here. @tangenta do you have any idea how to fix it?