SEZ9 commented on issue #12382:
URL: https://github.com/apache/seatunnel/issues/12382#issuecomment-5843245906
Thanks for the detailed timeline. The key signal is that `Committing offset
LSN{0/22BC778}` is derived from the last emitted change event, which suggests
the `id=15` event was decoded and handed off but never reached the sink, while
checkpoints kept completing every 5s.
Building on the plan above, the three boundaries worth instrumenting with
test-only evidence are the ones already listed: `PostgresWalFetchTask` handoff
(including startupOffset handling against records already buffered in the
Debezium queue right after restore), reader emission and the split state
restored from checkpoint 4 versus the freshly created fetcher, and JDBC sink
writer receipt/commit after restore. The most useful outcome is a clear answer
to whether the `id=15` row is absent before emission, after emission, or only
after the sink boundary.
Since this has only been seen once on a scheduled run, let's keep tracking
it here rather than retrying blindly. The committed offset advancing past an
undelivered row points to a possible correctness problem, but as noted above we
should not pick a fix direction or open a production-fix PR until that boundary
is demonstrated.
<!-- streview-comment:1332 -->
--
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]
