[Bug] [Zeta] the retry mechanism may have a serious bug

[Sephiroth1024]

Search before asking

• I had searched in the issues and found no similar issues.

What happened

Pre agreements:

• Take MySQL as an example.
• When we submit a job, seatunnel will query the current table structures in the target database and store them in AbstractDebeziumDeserializationSchema#tableChangesStructMap.
  Refer to it as tableChangesStructMap.
• To be simplified, assume that the worker will perform the checkpoint(actually the master does).
• Assume that there is a database and it has two tables, tb1 and tb2.

1. Now we submit a job.

2. Then a new table called tb3 is created.

3. Perform a checkpoint.

4. The task failed for some reason and master will retry. And something is wrong because the master's tableChangesStructMap is an old version (the only time when master builds tableChangesStructMap is when the job is submitted).

5. Perform a checkpoint. And the wrong table structures will be stored in the checkpoint file forever.

It may cause some exceptions like Can't obtain schema for table xxx.

It can also cause some debezium's exceptions like Data row is smaller than a column index. When the debezium starts, it will recover it's DatabaseSchema from DatabaseHistory. The seatunnel's implementation is EmbeddedDatabaseHistory, and it will recover from the latest checkpoint.

What kind of exceptions it may cause depends on what kind of DDL statements the database executes.

SeaTunnel Version

2.3.12

SeaTunnel Config

//

Running Command

//

Error Exception

//

Zeta or Flink or Spark Version

No response

Java or Scala Version

No response

Screenshots

No response

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[DanielCarter-stack]

Thanks for reporting this potential bug. The analysis suggests a real issue: when a Zeta CDC job restores from checkpoint after DDL changes occurred during execution, the master node's tableChangesStructMap in AbstractDebeziumDeserializationSchema may retain stale schema data, while workers have the updated map. This can cause Can't obtain schema for table xxx or Data row is smaller than a column index errors.

Key evidence:

• tableChangesStructMap is final and only initialized in constructor (AbstractDebeziumDeserializationSchema.java:48-58)
• Workers dynamically add new schemas via deserialize() but master doesn't process data streams
• Checkpoint stores worker's historyTableChanges (IncrementalSourceReader.java:267-282) but restoreCheckpointProducedType doesn't restore this map (SeaTunnelRowDebeziumDeserializeSchema.java:295-324)

To help verify:

1. Are you using Zeta engine with exactly_once=true?
2. Did the DDL change occur between checkpoints before failure?
3. Can you share the full exception stack trace?

This would be a valuable contribution if confirmed. A possible fix could involve restoring tableChangesStructMap in the checkpoint recovery logic.