SEZ9 commented on PR #12081: URL: https://github.com/apache/seatunnel/pull/12081#issuecomment-5628529903
@Rangsh — answering your F4 comment on `1de6f1b88` directly: yes, the fail-close approach addresses the concern I had. The mid-file tear only arises if APPEND keeps writing to the same stream after a failed write, so making `WALWorkHandler` sticky-block further APPENDs (`done(false)`, no stream touch) keeps any partial frame at the tail, where the existing trailing-frame stop in `DefaultReader` already handles it. Avoiding a blind `fs.create` reopen on the fixed `wal.txt` path is the right call too. `DefaultReaderTornMidFileRecordTest` pinning the "later intact frame is dropped" behavior is useful — it documents exactly why the fail-close is necessary rather than optional. On `f17373ac5`: exposing the sticky flag through `isAppendBlockedAfterWriteFailure()` → `WALDisruptor` → `IMapFileStorage.isAppendPermanentlyBlocked()` and having `FileMapStore.store()` / `storeAll()` throw `IMapStorageException` closes the part of F4 I was most worried about after the first fix — a fail-closed WAL that the caller can't see would have turned a torn record into silent data loss on the IMap side. The explicit "permanently blocked, restart required" message plus the `FileMapStoreTest` coverage is what I wanted. The Javadoc note that there is no in-process reset also resolves the clarity point. Two small remaining asks before I mark F4 resolved: 1. Your F4 comment got cut off mid-sentence at "`WALWorkHandlerSurvivabilityTest` — still proves the worker is…". Can you finish that thought? Specifically I want to confirm the test asserts that, after the first write failure, the disruptor worker stays alive and subsequent APPEND events still get `done(false)` (not left un-completed), since that overlaps with F2 (worker death) and F1 (callers hanging on a never-completed future). 2. Please confirm the fail-close also covers the case where the failure happens inside the flush/sync path rather than the `write` call itself, so the sticky flag trips on any exception out of the writer, not just on the append. Once those are confirmed I'll re-trace `f17373ac5` and update F4. <!-- streview-comment:955 --> -- 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]
