DanielLeens opened a new issue, #12164:
URL: https://github.com/apache/seatunnel/issues/12164

   ## What Problem Does This Issue Report?
   
   `TaskExecutionService.deployLocalTask` can leave a stuck `TaskGroupLocation` 
permanently un-redeployable after a task-submission failure that happens right 
after context publication - discovered while reviewing #11727 and #11757, but 
the affected code is pre-existing baseline logic, not introduced by either.
   
   ## Root Cause
   
   `deployLocalTask` 
(`seatunnel-engine/seatunnel-engine-server/src/main/java/org/apache/seatunnel/engine/server/TaskExecutionService.java`)
 does this inside `synchronized (this)`:
   
   ```java
   executionContexts.put(taskGroup.getTaskGroupLocation(), context);
   cancellationFutures.put(taskGroup.getTaskGroupLocation(), 
cancellationFuture);
   contextPublished = true;
   ```
   
   then, **outside** the lock: `onContextPublished.run()`, 
`submitThreadShareTask(...)`, `submitBlockingTask(...)`. The surrounding `catch 
(Throwable t)` only calls `onFailureBeforeContextPublished.accept(t)` `if 
(!contextPublished)` - which is always false by the time any of those three 
calls can throw (e.g. `RejectedExecutionException` from an executor 
mid-shutdown during a failover/restore window). So a throw there leaves the 
`executionContexts`/`cancellationFutures` entries in place with no rollback.
   
   That leak compounds with the guard in `deployTask`:
   
   ```java
   if (executionContexts.containsKey(taskGroup.getTaskGroupLocation())) {
       // "TaskGroupLocation %s already exists and is active, skipping redeploy 
..."
       return TaskDeployState.success();
   }
   ```
   
   Once the leaked entry exists, every future redeploy attempt for that exact 
`TaskGroupLocation` hits this branch and returns success **without deploying 
anything** - a silent, permanent job hang rather than a visible failure.
   
   ## Suggested Fix
   
   Add a rollback path (remove both map entries) that also runs when 
`onContextPublished`/`submitThreadShareTask`/`submitBlockingTask` throw after 
`contextPublished` is set, matching the existing `!contextPublished` branch's 
cleanup semantics.
   
   ## Where This Was Found
   
   Confirmed present, unmodified by either PR's own diff, on both 
apache/seatunnel#11727 (`fix/11679-blockingworker-start-latch`, head 
`18e821c3d`) and apache/seatunnel#11757 (`fix-11755-stale-context-race`, head 
`39312b92d`), and matches current `dev`. Originally flagged as part of a 
broader review by @SEZ9 on #11727.
   


-- 
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]

Reply via email to