xinnyuli commented on issue #12382: URL: https://github.com/apache/seatunnel/issues/12382#issuecomment-6108700346
Thanks @SEZ9. I retested on a build containing the merge. **Setup:** dev at `0278a6a74746856488dd27713736f008e3115c11` (includes #12454), Java 11, stress-ng on, no instrumentation, Debezium resume logging on. To keep the test fixed, `PostgresCDCIT.java` was taken from `146a1b5c` (the PR base, the same test that reproduced the loss), so only the production code differs from my earlier runs. **Result:** not reproduced. The id=15 row written while the job was stopped reached the sink in 30/30 runs (0 ROW_MISSING, 0 setup failures). The exact one-sided 95% upper bound on the per-run failure rate is 9.5%. **Boundary hits:** 3 of the 30 runs hit the exact condition from before, where the first WAL message after restart is at the stored commit-end LSN. All 3 replayed the transaction and delivered id=15, with nothing filtered as "already processed": | run | stored offset | first LSN on restart | id=15 starts at | outcome | |---|---|---|---|---| | n8 | 0/2228268 | 0/2228268 | 0/2228268 | delivered | | n12 | 0/222A2C8 | 0/222A2C8 | 0/222A2C8 | delivered | | n29 | 0/2226C98 | 0/2226C98 | 0/2226C98 | delivered | On `146a1b5c`, the same boundary lost the row in all three hits. On `0278a6a74` it delivered the row in all three, so the symptom in this issue is fixed in current dev. I'm happy for this to be closed. Run: https://github.com/xinnyuli/seatunnel-12382-repro/actions/runs/38117641803 -- 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]
