DanielLeens opened a new issue, #12120: URL: https://github.com/apache/seatunnel/issues/12120
## Description This is a design task for the pending-queue ordering contract across master failover. It is not a regression report, and the interrupted-insertion acknowledgement defect is tracked separately in #12010 / #12052; it is intentionally excluded here. Verified at `dev` commit `97d461bc0773399d632fd078735736ecd44f5f0b`: - `submitJob()` writes `JobInfo` into `runningJobInfoIMap` before queue insertion (`CoordinatorService.java:1374` path), so recoverable job metadata does exist. - The queue itself is in-heap: `PeekBlockingQueue.java:48` (`new LinkedBlockingQueue<>()`); `clearCoordinatorService()` (`CoordinatorService.java:1281`) calls `pendingJobQueue.clear()` (`:1311`) on step-down (`:1259`, `:1266`) and shutdown (`:2089`). - `restoreAllRunningJobFromMasterNodeSwitch()` (`:989`) iterates `runningJobInfoIMap.entrySet().stream()` with no ordering and rebuilds a `JobMaster` per job (`:1106-1160`). The original enqueue order is not preserved, and sorting by submit time would not reproduce it either because initialization is concurrent. Out of scope: disk durability or recovery after losing every `IMap` replica. ## Expected outcome - Define the FIFO/fairness contract that `WAIT` promises across a master failover. - Persist an enqueue sequence with the job metadata and re-queue in that order on restore. - Coordinate with the admission-contract work so restore does not eagerly re-plan every queued job. - Test: queue 50 jobs in `WAIT`, kill the active master, assert the same relative order after restore. -- 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]
