yigitcan-ozturk commented on issue #12125: URL: https://github.com/apache/seatunnel/issues/12125#issuecomment-5917274889
Hi @DanielLeens — I'd like to take the reproduction-first investigation for this issue. I'll keep the first phase strictly on current `dev` and will not treat the no-op `SeaTunnelServer#reset()` as a defect until the merge-specific failure chain is reproduced. My first deliverable will be a controlled cluster-merge reproducer/evidence pass matching the issue boundary: - start a streaming job with checkpoints and record member IDs, master/worker roles, `TaskGroupLocation` values, slot ownership, and checkpoint progression; - `SIGSTOP` one worker beyond the heartbeat timeout and confirm eviction; - `SIGCONT` it and capture the losing-side rejoin/cluster-merge path, including whether `SeaTunnelServer#reset()` is invoked; - after convergence, fail the active master and observe whether the surviving/rejoined worker execution state is reconciled correctly and checkpoints continue; - distinguish a stale local `executionContexts` entry from an actual recovery failure rather than using the entry itself as proof. I'll keep the investigation separate from implementation. If the gap reproduces on `dev`, I'll post the evidence and proposed lifecycle boundary first, then follow with a focused fix through the existing completion/resource-release path, with idempotence and regression coverage. If it does not reproduce, I'll report that result and the captured state transitions rather than forcing a patch. If this scope is still available, I'm happy to own the investigation. -- 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]
