DanielLeens commented on issue #11679: URL: https://github.com/apache/seatunnel/issues/11679#issuecomment-5231453972
Thanks, this materially narrows the issue. I re-checked the current `dev` code path against the new artifacts you posted on August 9, 2026, and the direction now looks more engine-side than client-side: 1. `ClientJobProxy.waitForJobCompleteV2()` blocks on `doWaitForJobComplete().get()`, so the stuck `seatunnel.sh` client is consistent with the engine never completing or publishing a terminal `JobResult`. 2. `SubPlan.handleCheckpointError()` goes back through `updatePipelineState(CANCELING)`. 3. `TaskExecutionService.submitBlockingTask()` waits on `startedLatch.await()` until every `BlockingWorker` starts and counts down. So if one coordinator thread is inside the synchronized `SubPlan` state/deploy path while waiting for that latch, another thread trying to enter `updatePipelineState()` from checkpoint-error handling can indeed be blocked behind the same monitor. That matches the shape of the dump much more closely than the earlier "client poll only" hypothesis. The next highest-value investigation step is the one you suggested: trace why the expected `BlockingWorker` never starts / counts down during the repeated restore path, and why the third deployment can stay in `DEPLOYING` long enough to prevent the terminal transition from being recorded. I would keep #11718 as containment only. The primary fix for this issue should stay engine-side and prove two things: - the repeated restore/deploy path cannot leave `startedLatch.await()` holding up checkpoint-error cancellation/state publication; - once the pipeline becomes unrecoverable, the submitting client receives a terminal result instead of waiting indefinitely. If you continue on this path, a Draft PR with focused logging or a targeted regression test around the repeated restore/deploy cycle would already be a very good next step. -- 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]
