Rangsh commented on PR #12081: URL: https://github.com/apache/seatunnel/pull/12081#issuecomment-5629167341
@SEZ9 thanks — answering the two remaining F4 confirms on `f17373ac5`: **1. Survivability test / incomplete sentence** Finishing the earlier thought: `WALWorkHandlerSurvivabilityTest.nonIoExceptionFromWriteShouldNotKillWorkerAndSubsequentAppendIsFailClosed` asserts all of: - first `onEvent(APPEND)` returns normally (`assertDoesNotThrow`) even when `writer.write()` throws a non-`IOException` (`IllegalStateException`) — so the sole Disruptor worker is not killed (F2); - that first future is completed with `done(false)` (`isDone()` + `get() == false`) — callers are not left hanging (F1); - second `onEvent(APPEND)` also returns normally, completes with `done(false)`, does **not** call `writer.write()` again (`writeCalls == 1` / `verify(..., times(1))`), and `isAppendBlockedAfterWriteFailure()` stays sticky. **2. Fail-close on flush/sync failures** Yes for the current write path: `WALWorkHandler` wraps `writer.write(...)` in `catch (Exception)`, and `HdfsWriter.write` always ends in `flush()` (the single `hsync`-family call). Any exception from the flush/sync path therefore trips the same sticky `appendBlockedAfterWriteFailure` flag and subsequent APPENDs complete with `done(false)` without touching the stream — same as a failure from the append/`write` bytes themselves. Happy to re-trace once you’ve checked these two points against `f17373ac5`. -- 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]
