SEZ9 commented on issue #12382: URL: https://github.com/apache/seatunnel/issues/12382#issuecomment-5903176733
Thanks @xinnyuli — this is exactly the evidence that was asked for, and the uninstrumented control settles the most important open question: the `expected: <1> but was: <0>` delivery failure reproduces on both c7304ace and 4c874e2a with the untouched upstream test under load, so the loss is not an artifact of the tracing agent. Keeping the committed-LSN setup timeout out of the denominator and reporting the reached count per row is also the right way to record this. A few notes on how I read the table: - 2/30 and 1/30 uninstrumented on baseline and dev means the row loss is now reproducible, if rare, and it is present on both revisions. That says the behaviour predates the dev revision rather than being introduced by it, but as you point out, the sample is too small to say anything about the delta between the groups or about whether tracing shifts the rate. - The no-load result (0/29 per revision) staying clean is consistent with a timing window that only opens under contention, which fits the original scheduled failure better than a deterministic bug would. Your last comment appears to have been cut off at "Since row loss is now r" — could you repost the remainder? I would like to see what you were proposing before agreeing on the next step. Assuming the rest goes where I expect, the next step within this investigation is the test-only correlation trace that was previously gated on reproducibility: for each failing run, capture (a) whether the reader ever emitted `id=15` after reattachment, (b) the checkpoint/committed-LSN advancement relative to that row's WAL position, and (c) whether the JDBC sink received it. Please keep that on the same two revisions, keep the load matrix recorded separately from the no-load runs, and keep reporting reached/not-reached alongside row-missing. Still no production tracing or fix PR at this stage — once the trace shows which stage drops the row, we can talk about the fix. <!-- streview-comment:1419 --> -- 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]
