SEZ9 commented on PR #12014: URL: https://github.com/apache/seatunnel/pull/12014#issuecomment-5825497275
Thanks @det101 for the F1 follow-up at `25baad9e3`. **1. Docs (failed TRUNCATE after a successful flush)** — The wording you describe (flush and `TRUNCATE` are not one transaction, `TRUNCATE TABLE` commits immediately, flushed rows stay committed on a later `TRUNCATE` failure, replayed truncate is idempotent but the window can still produce duplicates) matches what F1 asked for, and keeping `docs/en` and `docs/zh` `Jdbc.md` / `MySQL-CDC.md` aligned is good. I still need to read the changed docs myself before marking this part resolved — could you point me to the relevant hunks in `25baad9e3`, and confirm whether `Jdbc.md` also states that the exactly-once (XA) writer rejects `TRUNCATE` at runtime? **2. XA + TRUNCATE rejection test** — Understood that the check from `1a4f2d32` is a runtime fail-fast in `JdbcExactlyOnceSinkWriter.applyTableOperation`, not job-submission config validation, and that `JdbcExactlyOnceSinkWriterTest.applyTableOperationIsRejectedOnXaWriter` covers it. Since F1 is HIGH severity, I'd like to verify the test against the diff rather than close it on description alone; if you can point me to that test in `25baad9e3` I'll do that and then update the finding. **F4** — Agreed it remains the known E2E gap (mid-flight restore between truncate and the next completed checkpoint). Not blocking F1; please just say whether you plan to address it in this PR or in a follow-up. Nothing else outstanding on F1 from my side beyond the two verification items above. <!-- streview-comment:1290 --> -- 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]
