SEZ9 commented on PR #12271: URL: https://github.com/apache/seatunnel/pull/12271#issuecomment-5923466326
Thanks for the follow-up commit. Re-checked at 3d57b64ddde against the three earlier points: **F1 (stale generation vs. new generation's loaders)** — The lookup half looks addressed: `deployLocalTask()` hands the exact `TaskGroupContext` instance to the `TaskGroupExecutionTracker`, and the cooperative hot loop now resolves through `tracker.getTaskClassLoader(taskId)`, which throws when the context's loaders are null instead of silently returning `null`. What I still can't confirm is the terminal cleanup path (`recycleClassLoader`/`taskDone`): is it still location-keyed, or does it now act on the tracker-owned context as well? A pointer to that part of the change would help. **F2 (`BlockingWorker` location-keyed lookup)** — Looks resolved. `BlockingWorker.run()` now resolves via `getTaskClassLoader(taskId)` on the tracker-owned context inside the existing try/catch, with `startedLatch.countDown()` remaining the first unconditional statement, so `ThreadShareMode.OFF` and non-sharing `PART` tasks get the same generation-safe behaviour as cooperative tasks. **F3 (regression test strength)** — Could you point me to the updated test? I'd like to confirm it exercises the fixed path: two generations at one `TaskGroupLocation`, generation A's worker receiving A's loader, and A's cleanup leaving B's loaders intact. <!-- streview-comment:1435 --> -- 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]
