SEZ9 commented on issue #11437: URL: https://github.com/apache/seatunnel/issues/11437#issuecomment-5149901700
Thanks for the detailed report. The 'Steps to reproduce' section appears to be cut off — could you complete it and attach the replacement Master's logs around the restore (especially ResourceManager / SlotService entries) plus Worker-side slot logs? That would help confirm where slot ownership state diverges after failover. This looks like the replacement Master's ResourceManager is not reconciling slot assignments still held by the Workers after failover: the old slots are neither reused for the restored pipelines nor released, so fixed-slot allocation blocks before deployment. The fact that cancellation does not free the Worker-held slots suggests a second leak in the release path when the owning Master changed. Can you check whether the Workers ever received a slot release/reset request from the new Master? Related but distinct from #10568/#9807 as noted — #10567 fixed idempotent redeployment, while this blocks earlier in resource allocation. Marking as a Zeta failover/slot-management bug; a workaround for now is dynamic-slot mode or restarting Workers, but the reconciliation gap should be fixed on the Master side. <!-- streview-comment:29 --> -- 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]
