DanielLeens opened a new pull request, #13101:
URL: https://github.com/apache/seatunnel/pull/13101
Yes, contributing to SeaTunnel.
### Purpose of this pull request
Adds an E2E regression guard for #11437 ("Fixed-slot streaming job remains
PENDING and leaks slots after active Master failover"), fixed by #11458
("[Fix][Zeta] Reuse fixed slots after master failover"). Test-only change; no
production code is touched.
### Why existing tests miss it
- #11458 added only unit tests (`JobMasterMasterFailoverResourceTest`,
`ResourceManagerTest`) that mock the ResourceManager; no real Worker slot pool
is involved.
- `SplitClusterFaultToleranceIT#testStreamJobRestoreInMasterDown` and
`CheckpointCoordinatorFailoverIT` kill the master with dynamic slots, where a
fresh slot request always succeeds, so the bug cannot surface.
- The only fixed-slot split-cluster test,
`testManyPipelinesRestoreContentionInWorkerDown`, kills a Worker (its slots
disappear with it) and is currently `@Disabled` (#12202).
### What the test does
New method
`SplitClusterFaultToleranceIT#testFixedSlotStreamJobReusesSlotsAfterMasterDown`:
1. Starts 2 masters (`WAIT` schedule strategy, as in the issue) and 1 Worker
with `dynamic-slot=false` and `slot-num=4`.
2. Submits a streaming FakeSource -> LocalFile job with parallelism 2. From
`PhysicalPlanGenerator`, it creates 2 reader/writer task groups + 1
split-enumerator coordinator + 1 aggregated-committer coordinator = 4 slots, so
the job uses the whole pool.
3. Waits until all vertices are RUNNING, at least 2 checkpoints are
completed, and the Worker's `SlotService` reports exactly 4 assigned slots
owned by the job.
4. Shuts down the active master and waits for the standby to become the
active coordinator.
5. Asserts that within bounded time every vertex is RUNNING again on the new
master, and that a checkpoint with a higher id completes after the failover.
6. Asserts the Worker still holds exactly 4 slots owned by the job (reused,
not requested again), then cancels the job and asserts the job ends CANCELED
and the Worker's assigned slots drop to 0.
### How it fails on pre-fix code
Without #11458, the restored `JobMaster#preApplyResources` asks for 4 new
slots while the Worker still has all 4 assigned, so no request succeeds. Under
`WAIT`, the job stays PENDING, so `assertAllVerticesRunning(standbyMaster,
jobId, 180)` times out (PhysicalPlan job status is PENDING, not RUNNING), and
no checkpoint completes after the failover.
### Does this PR introduce any user-facing change?
No.
### How was this patch tested?
Only spotless runs locally; GitHub CI is the verification.
### Check list
- [x] Test-only change; no new dependencies, no docs change needed.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
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]
