hutiefang76 opened a new issue, #12509: URL: https://github.com/apache/seatunnel/issues/12509
### What happened When a worker is lost and replacement capacity is not registered yet, a pipeline recovery can continue deploying tasks after resource allocation fails. I reproduced a task failing with `WrongTargetSlotException: Unknown slot`; the replacement worker subsequently joined, but the job did not finish within the 180-second observation window. The recovery branch in `SubPlan.stateProcess()` calls `jobMaster.preApplyResources(this)` and ignores its boolean result. When allocation fails, `JobMaster` releases the attempted allocation without replacing the plan's pre-applied resource futures, so continuing recovery can deploy using stale slot information. ### Reproduction - Zeta cluster: one Master JVM, two Worker JVMs, two fixed slots per Worker. - Bounded sequence source with two readers and two chained JDBC sinks; the pipeline requires three slots. - Enable a 2-second checkpoint interval. After checkpoint 1 completes, kill a Worker executing a writer task with SIGKILL. - Start a replacement Worker at a different address while the Master remains alive. - The first recovery attempt lacks sufficient slots, but still proceeds to deployment and reports `Unknown slot`. I encountered this with PostgreSQL-backed DuckLake metadata and S3 data, but the unchecked resource-allocation result is in the engine and is not specific to that connector. The focused unit regression reproduces it on dev `146a1b5c5`. A minimal check that stops deployment when `preApplyResources` returns false allows the existing bounded retry path to recover once capacity is registered. In the same real cluster experiment, both ordinary and bulk append completed after three recovery attempts with all 400 distinct input IDs on the replacement worker. Bulk replayed 10 rows, which is expected for append-only delivery; this does not establish exactly-once semantics. -- 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]
