Panic occur in checkIneligibleTableDDL

[CharlesCheung96]

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x3f9ae71]

goroutine 604 [running]:
github.com/pingcap/tiflow/cdc/puller.(*ddlJobPullerImpl).checkIneligibleTableDDL(0xc004ccbd80, 0xc003b45ea0, 0xc00277d520)
	github.com/pingcap/tiflow/cdc/puller/ddl_puller.go:518 +0xb1
github.com/pingcap/tiflow/cdc/puller.(*ddlJobPullerImpl).handleJob(0xc004ccbd80, 0xc00277d520)
	github.com/pingcap/tiflow/cdc/puller/ddl_puller.go:488 +0x3157
github.com/pingcap/tiflow/cdc/puller.(*ddlJobPullerImpl).handleRawKVEntry(0xc004ccbd80, {0x6054320, 0xc003a1d770}, 0xc000e6e0e0)
	github.com/pingcap/tiflow/cdc/puller/ddl_puller.go:204 +0xdc
github.com/pingcap/tiflow/cdc/puller.(*ddlJobPullerImpl).Run.func3()
	github.com/pingcap/tiflow/cdc/puller/ddl_puller.go:151 +0xb5
golang.org/x/sync/errgroup.(*Group).Go.func1()
	golang.org/x/sync@v0.9.0/errgroup/errgroup.go:78 +0x50
created by golang.org/x/sync/errgroup.(*Group).Go in goroutine 600
	golang.org/x/sync@v0.9.0/errgroup/errgroup.go:75 +0x96

[CharlesCheung96]

Investigate

The directly reason

1. Some DDL statements with ifNotExists/ifExists may not actually be executed because the condition is not met, resulting in Schemaversion being set to 0 after it is committed.
2. After this fix, ddl job can not be filtered by Schemaversion.
3. Then, the panic occus when access a uninitialized tableinfo here

The root cause

The ddl-related implementation of TiCDC is not aligned with TiDB's, so it is easy to cause inconsistencies due to miscalculations in some details such as ddl query, id, and schema related information.

Proposal

From @D3Hunter, we need to clearly define the contract for ddl replication and specify the constraints that ddl job meta must meet when the DDL event is set to the done state.