DanielLeens commented on PR #12081: URL: https://github.com/apache/seatunnel/pull/12081#issuecomment-6258245056
@SEZ9 thanks for the careful follow-through. I can answer the F4 question with what is on `ab04db33a`, so you do not have to infer it from the test name. It is closest to your option (b), with one precision on what the test does and does not prove. - The mitigation for the torn-record risk is the sticky fail-close, not a re-read of the file. After the first `writer.write(...)` failure, `WALWorkHandler` sets `appendBlockedAfterWriteFailure = true` (`WALWorkHandler.java:111-113`), and every later APPEND returns early at `WALWorkHandler.java:99` without touching the writer. So no further bytes are ever appended after a possibly partial record by the same handler. - `WALWorkHandlerSurvivabilityTest` pins exactly that. `assertFailCloseAfterFirstWriteFailure` (`WALWorkHandlerSurvivabilityTest.java:132-184`) drives one failing APPEND and then a second APPEND on the same handler. It asserts both futures complete with `false`, the writer is invoked once (`verify(failingWriter, times(1)).write(...)`, `writeCalls == 1`), and `isAppendBlockedAfterWriteFailure()` stays true. It is exercised for both a non-IO exception from `write` (L66) and a flush failure from `HdfsWriter` (L91). If the sticky flag were removed, the second APPEND would hit the writer again and `times(1)` would fail. - What the test does not assert: it uses a mocked writer, so it does not read the WAL file back. The claim is "no append follows a failed write", not "the file is still readable". Recovering from a partially written tail record on the next restore is the reader side's existing behaviour and is unchanged by this PR as far as I can see, so I would treat it as out of scope here. This is separate from F2 (worker liveness): the `assertDoesNotThrow` around `onEvent` covers F2, while the `times(1)` plus sticky-flag assertions cover F4. Regarding the F8 sentence that looked cut off, that one is for @Rangsh to complete, so I will leave it to them. Thanks again both. -- 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]
