SEZ9 commented on issue #12382: URL: https://github.com/apache/seatunnel/issues/12382#issuecomment-6116518858
Thanks @xinnyuli for the thorough retest on `0278a6a74746856488dd27713736f008e3115c11`. Keeping `PostgresCDCIT.java` pinned to `146a1b5c` so that only the production code differed was the right control, and 30/30 deliveries of `id=15` with no setup failures is clear. The three boundary hits (n8, n12, n29) are the decisive part: in each, the stored offset, the first LSN on restart, and the `id=15` transaction start are the same value (e.g. `0/2228268`), and the transaction was replayed rather than filtered as already processed. Since that identical boundary lost the row on `146a1b5c` in all three hits, this confirms the restore LSN handling now behaves correctly on current `dev`. The linked run (38117641803) is a useful reference for anyone revisiting this. To be explicit about scope: this confirms the fix in current `dev`, not in any earlier released build. Nothing further is needed from you. The evidence supports closing this issue; a repository maintainer with issue-state permission can close it based on your retest. If a distinct reproduction appears later, please open a new report with the exact version, the restored offset, the first WAL LSN after restart, and the sink result, as you did here, so we can tell a new boundary apart from the one that was fixed. <!-- streview-comment:1684 --> -- 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]
