DanielLeens commented on issue #11679: URL: https://github.com/apache/seatunnel/issues/11679#issuecomment-5210720156
Thanks for separating this from the narrower test-time mitigation in #11648 and for documenting the runtime path so concretely. This does look like a real Zeta-side bug rather than a test-only problem. From your description, the cluster reaches a terminal cancellation path after the downstream privilege failure, but the client-side `seatunnel.sh` wait loop never observes a terminal job state and therefore never returns control to the caller. That means the user-visible problem is not the authorization failure itself, but the missing terminal-state handoff back to the submitting client. The likely investigation path is exactly where you pointed: 1. how the pipeline cancellation / restore path records the final job outcome after repeated checkpoint-error handling; 2. how the engine client polls and decides that a submitted job has reached a terminal state; 3. whether there is a race where the job leaves the active counters before the client can ever observe `FAILED` or `CANCELED`. As a temporary mitigation, bounding the affected E2E invocation in #11648 still makes sense because it limits CI blast radius, but I agree that it does not solve the engine behavior reported here. I've labeled this as `bug` and `help wanted` so it is visible to contributors familiar with the Zeta lifecycle path. If anyone investigates this further, the most valuable next evidence would be a focused reproduction plus the exact client poll/status path showing where terminal visibility is lost. -- 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]
