li3zhi4 commented on PR #11677: URL: https://github.com/apache/seatunnel/pull/11677#issuecomment-5214946556
Thanks for the detailed engine-level trace — it's correct, and I've converged on it. **Issue 1 (Medium) — reachability confirmed, narrative adjusted:** I traced the same chain on the current head: a reader's `restoreState()` synchronously delivers its checkpoint-restored splits via `RestoredSplitOperation` *before* it registers, and the enumerator's `run()` only fires once all readers have registered (`SourceSplitEnumeratorTask` STARTING → RUNNING). So in a clean single-parallelism full-pipeline restart — exactly the scenario the e2e drives — `running` is typically still `false` when `addSplitsBack()` is invoked, and the literal "reader registers, then split restores late" ordering is not the dominant path on dev today. The enumerator-level defect remains real and reachable whenever `addSplitsBack()` races `run()`/`handleSplitRequest()` with `running == true` (multi-reader interleaving, retry-induced delay, scheduling variance), which the deterministic unit test proves independent of engine timing. I've updated the PR description with a "Reachability note" reflecting exactly this, and reframed the fix as necessary defensive hardening at the enumerator's contract boundary rather than *the* mechanism of the production stall. **Issue 2 (Low) — comment added:** `SourceSplitEnumeratorTask.receivedReader()` now carries a comment at the reader-registration gate documenting the cross-class invariant (reader restores synchronously before registering; run() fires only after all readers register) and noting that `IncrementalSourceEnumerator.addSplitsBack()` defensively re-runs assignment when that ordering does not hold. Both changes are in commit `1684c382f` (pushed). spotless:check passes on the affected module; the unit test remains green. A debug-log trace of the exact e2e interleaving on a real run remains a good follow-up as you suggested, but I believe the narrative now matches the engine behavior as traced. -- 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]
