SEZ9 commented on PR #12014:
URL: https://github.com/apache/seatunnel/pull/12014#issuecomment-5806730869
Follow-up on F1 after the trace against `a36c6f440068`:
The ordering argument holds up: `applyTableOperation()` calls
`prepareCommit()` first, both branches of `prepareCommitInternal()` hit
`checkFlushException()` before `flush()`, and `checkFlushException()` is
untouched by the `commitOnFlush`/latch changes, so a stale flush failure aborts
before `dialect.applyTableOperation(...)` is reached. That covers the "TRUNCATE
issued on top of a failed flush" half of F1, and since `b9f6da93..a36c6f440068`
doesn't touch this PR's classes or `JdbcOutputFormat.java` /
`AbstractJdbcSinkWriter.java`, I'm satisfied the invariant survives the dev
merge.
What's still open on F1 is the other half - the flush succeeds and commits,
then the TRUNCATE itself fails (FK constraint, permissions, etc.). Because
TRUNCATE is DDL with an implicit commit, there is no transaction to roll back
at that point; the job fails and the checkpoint replay re-delivers
already-committed rows plus the pending TRUNCATE. That is the documented
at-least-once behavior, and I agree it doesn't need a code change, but I'd like
two things before resolving:
1. In `docs/en/connectors/sink/Jdbc.md`, spell out explicitly that a failed
TRUNCATE (FK violation being the concrete example) leaves the preceding flush
committed and relies on restore to re-apply, so users understand duplicates are
possible in that window. Right now the limitation is implied rather than stated.
2. Point me at the test that exercises the rejection added in `1a4f2d32d6fe`
(XA exactly-once + TRUNCATE table-operations at config validation). If there
isn't one yet, please add it - that check is what makes the XA part of F1 safe,
and it shouldn't be able to regress silently.
Also note the last comment appears to have been cut off mid-sentence ("I
don't see this needing a code cha..."); if there was more to the conclusion,
please re-post it so nothing is lost.
Once (1) and (2) are in, I'll mark F1 resolved. The restore/failover
coverage gap in F4 is the natural place for the replay scenario described
above, so feel free to fold them together.
<!-- streview-comment:1279 -->
--
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]
