SEZ9 commented on PR #12081: URL: https://github.com/apache/seatunnel/pull/12081#issuecomment-5852100394
Thanks for the detailed follow-up. **F4 / F2:** The fail-closed approach (sticky `appendBlockedAfterWriteFailure` flag, subsequent APPENDs answered with `executeResponse(requestId, false)` without touching the writer) sounds like a reasonable trade-off given the torn-frame constraints you describe, and `DefaultReaderTornTrailingRecordTest`, `DefaultReaderTornMidFileRecordTest` and `WALWorkHandlerSurvivabilityTest` look like the right coverage. I'll re-check the diff to confirm before marking these resolved. **F1:** Agreed that an `Error` escaping `writer.write()` is worth tracking separately — please link the issue here once it's opened. One related question: does any production path still call the untimed `RequestFuture.get()`, or does everything now go through the timed variant? **F6:** Your comment appears to have been cut off right after confirming that `batchQueryExecuteFailsStatus` computes `deadlineNanos` once and each entry waits `Math.max(0, deadlineNanos - now)`. That is the behavior I was hoping for. Could you repost the rest, and let me know whether there is a test covering the bounded total wait? **F3 / F5 / F7 / F8:** Could you briefly summarize where these stand (method-level Javadoc and remaining boolean-return callers for the timed `get`, the Mockito test dependency for `HdfsWriterFlushSyncPathTest`, and the logging level/verbosity of timed-out waits in `queryExecuteStatus`)? A short note per item is enough so I can verify against the latest changes. <!-- streview-comment:1353 --> -- 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]
