DanielLeens commented on PR #12081: URL: https://github.com/apache/seatunnel/pull/12081#issuecomment-6567768275
Thanks @SEZ9 for the continued review, and @Rangsh for the pointers. On your question about how the handler leaves the blocked state: it does not, by design, and the code already says so. In `WALWorkHandler` (head `ef99d22d1`), the Javadoc on `appendBlockedAfterWriteFailure` states that it is sticky for the handler's lifetime, is never reset in-process, and needs an engine-node restart to clear. The class Javadoc gives the reason: after a partial write, a later complete frame would sit behind a torn one and `DefaultReader` cannot resync past a mid-file tear, and reopening with `fs.create` would truncate the fixed `wal.txt` path. So no extra comment is needed on that flag. For the item you did not have a pointer for, as I read it on this head: - **F2**: the `writer.write(...)` call is inside the `try`, which catches `Exception` rather than only `IOException`, so the `done(...)` response is always published. `executeResponse` has its own `try/catch` around `RequestFutureCache.get` and `future.done`, so a failure while publishing the response is logged and cannot kill the single consumer thread. One thing is still worth checking on your side: the callers outside this module that react to the blocked state, `FileMapStore` (via `isAppendPermanentlyBlocked()`), since that is where a permanent block turns into an observable failure for checkpoint storage. This is a static read; I did not run anything locally. My latest full review of `ef99d22d1` is unchanged by this reply. -- 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]
