SEZ9 commented on issue #12382:
URL: https://github.com/apache/seatunnel/issues/12382#issuecomment-6105115965

   @xinnyuli, thank you for the real-run comparison — the side-by-side table is 
exactly what was needed. In all three missing-row runs on the PR base 
`146a1b5c`, the stored commit-end LSN, the first LSN after restore, the LSN 
filtered as "already processed", and the start of the `id=15` transaction are 
the same value (e.g. `0/2228138` -> `0/2228270` in n18), while the two 
post-#12454 runs (`3080371c`) that hit the same boundary filtered nothing there 
and delivered `id=15`. I agree the 3/30 vs 0/28 rate alone is not significant; 
the boundary-hit rows are the decisive evidence for this symptom, and the n10 
single-message case (stored `0/221F028`, `id=15` starting later at `0/22278D8`) 
is consistent with that, since no row was dropped.
   
   Status: #12454 has since been merged into `dev` at 
`0278a6a74746856488dd27713736f008e3115c11` on 2026-10-09. It carries the 
message-type-aware PostgreSQL offset/locator handling while still reading 
legacy savepoints, and its tests cover the shared commit/row-LSN boundary you 
reproduced. This is a fix in current `dev`, not a claim about any released 
build.
   
   Remaining asks:
   1. If you can, retest your savepoint/restore sequence on a build containing 
that merge (or a later release) and report the exact version and the sink 
result for the row written while stopped.
   2. If it no longer reproduces, say so and we can close this issue.
   3. If it still reproduces, please include the restored offset, the first WAL 
LSN after restart, and the exact sink result, so we can tell a new boundary 
apart from the one #12454 addressed.
   
   Please don't open a separate production-fix PR for this; any further 
deterministic assertion should build on what landed from #12454.
   
   <!-- streview-comment:1670 -->


-- 
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]

Reply via email to