unstable test `syncpoint`

[hongyunyan]

link: https://do.pingcap.net/jenkins/blue/organizations/jenkins/pingcap%2Fticdc%2Fpull_cdc_mysql_integration_heavy/detail/pull_cdc_mysql_integration_heavy/6033/pipeline

[hongyunyan]

We categorize DDLs into three types: normal (affecting only a few tables), db (affecting all tables in a given database), and ALL (affecting all tables in a given database).

When the maintainer receives a DB/ALL type DDL status report from a table trigger event dispatcher, it creates a range checker based on the replica information available in the spanController at that time. This checker verifies whether all affected dispatchers have reported their statuses. Only after all affected dispatchers have reported their statuses can the DDL execution begin.

For DDLs like create table/truncate table, which increase or decrease the number of replicas in the spanController, the maintainer calls scheduleBlockEvent to modify the spanController after the DDL is successfully written. However, there's a current issue: the execution of the scheduleBlockEvent for the previous DDL might be later than the arrival time of the next DDL in the maintainer's queue, because these two operations are asynchronous.

Suppose a table trigger reports a DDL for truncate a table, and the maintainer agrees, requiring the table trigger to truncate the table downstream. When the table trigger finishes writing, the dispatcher receives the next DDL/syncpoint and reports it to the maintainer. The table trigger also notifies the maintainer that it has finished truncate the table. The maintainer can only begin executing the scheduleBlockEvent after receiving this message. Therefore, the order of these two operations is not fixed.

Suppose the later syncpoint arrives at the maintainer first. The maintainer creates a range checker based on the existing replica information in the spanController. This checker will not include the newly generated dispatcher for truncate the table, and the maintainer will not wait for this dispatcher to receive this syncpoint before considering it ready to execute. Therefore, when comparing this syncpoint, the data in the table where this dispatcher resides may be inconsistent.

Therefore, to avoid this problem, we need to ensure that when the maintainer creates a range checker of type db/all, all preceding DDLs that may affect the spanController have been scheduled.