zhang-arvin commented on issue #12212: URL: https://github.com/apache/seatunnel/issues/12212#issuecomment-5598440980
## Root cause analysis (withdrawing my claim) After digging into the codebase I'm unassigning myself from this one and leaving the findings for whoever has a real binlog to reproduce with. **Findings:** 1. SeaTunnel vendors Debezium 1.9.8 code (`connector-cdc-mysql/src/main/java/io/debezium/`), but the actual rows deserialization lives in the `debezium-connector-mysql-1.9.8.Final.jar` (`RowDeserializers`), which extends zendesk's `mysql-binlog-connector-java` 0.25.3. 2. `deserializeDatetimeV2` unconditionally does `read(5)` and LONGLONG unconditionally reads 8 bytes — no length guard; short data goes straight to EOFException. 3. The deserialization core class bytecode is **byte-identical between zendesk 0.25.3 and 0.27.2** — this bug is unfixed upstream for years. 4. Checked Debezium 2.0.0: no boundary fix there either (only FAIL/WARN handling modes were added), so there is nothing portable to vendor. 5. The EOF propagates via EventDataDeserializationException → pseudo INCIDENT event → `handleServerIncident` → `RuntimeException`, permanently stopping the connector (not reconnecting). The row data loss on restart is a checkpoint-window semantic (EXACTLY_ONCE, 30s interval) — rows read but not yet checkpointed are not re-read after restart. That part cannot be fixed at the connector layer. A minimal mitigation (detect deep IOException in `handleServerIncident` and rethrow to force reconnect) is possible, but without a real binlog reproduction I can't validate it properly. Leaving the issue open for the upstream fix. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
