SEZ9 commented on PR #12081: URL: https://github.com/apache/seatunnel/pull/12081#issuecomment-5650131467
@Rangsh thanks for closing the loop on both F4 points against `6d7e999f0`. **1. Survivability test (F1/F2/F4)** — the behavior you describe is exactly what I was asking for: worker survives a non-`IOException` from `writer.write()`, the first future completes with `done(false)`, and the second APPEND is fail-closed with `write()` invoked once and `isAppendBlockedAfterWriteFailure()` sticky. I'll verify `WALWorkHandlerSurvivabilityTest.nonIoExceptionFromWriteShouldNotKillWorkerAndSubsequentAppendIsFailClosed` against the `6d7e999f0` diff before I flip F4 to resolved; no production change requested from my side. **2. Fail-close on flush/sync** — understood, and that answers the caveat I raised on `f17373ac5`: since `WALWorkHandler` catches `Exception` around `writer.write(...)` and `HdfsWriter.write` always terminates in the single `flush()`/`hsync`-family call, a failure in the sync path trips `appendBlockedAfterWriteFailure` identically to a failure writing the record bytes, so there is no path where the stream is touched again after a torn write. One small ask: your comment was cut off at "There was previously" — could you finish that sentence? If it describes a prior behavior or earlier revision that differs from what is on `6d7e999f0`, I want to make sure it is captured before I mark F4 resolved. Once I have that and have checked the test against the diff, I'll update the F4 status. <!-- streview-comment:997 --> -- 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]
