DanielLeens commented on PR #12079: URL: https://github.com/apache/seatunnel/pull/12079#issuecomment-6266728551
Thanks @SEZ9 for the careful follow-up. I re-checked each open item against the current head `612b5ede517b5f7b800c2695c8e2f3e88a789b97` (the head is unchanged since my last review), and I believe all four are already closed on this head. Details with locations so you can verify directly: **1. F3 (single resolution path).** Transforms resolve their IDs exactly once, in the `ScheduledTransform` constructor: `TransformDependencyScheduler.java:235` calls `ConfigParserUtil.getInputIds(readonlyConfig)`, and exposes the results via `getOutputId()` (`:247`) and `getInputIds()` (`:251`). `DryRunConnectValidator.validateTransform` reads `scheduledTransform.getOutputId()` / `getInputIds()` (`:240`, `:242`) instead of re-parsing the config. There is no `getTransformInputIds` / `getTransformOutputId` helper left. The one remaining `getInputIds(readonlyConfig)` call in `DryRunConnectValidator` (`:305`) is in the sink validation path, which has no scheduler involvement, so it cannot diverge from transform scheduling. **2. F7 (docs).** Present in both languages: `docs/en/introduction/concepts/incompatible-changes.md:104` (`### Transform Dependency Resolution`) and `docs/zh/introduction/concepts/incompatible-changes.md:75` (the matching Transform dependency entry). They describe the fail-fast behavior (`JobDefineCheckException` at Zeta parse time, `ConfigCheckException` in connect dry-run), including explicit self-references in single-transform jobs. Your request to record in the PR description which previously accepted multi-transform configs now fail is also covered: the PR body states that the old resolver could loop indefinitely on cyclic graphs and could build a multi-input transform from only the inputs already available, silently dropping the remaining upstreams. **3. F8.** `getOutputId()` on `ScheduledTransform` has production callers (`MultipleTableJobConfigParser` and `DryRunConnectValidator.validateTransform`), and the static `getOutputId` helper no longer exists in `ConfigParserUtil`. **4. Build.** The required `Build` check is now `SUCCESS` for this head (completed 2026-10-19T05:22Z, fork run https://github.com/goutamadwant/seatunnel/actions/runs/39008501172). This is a statement about that specific run on `612b5ede5`, not about any later head. On my side there is no remaining source-side blocker, and I have not run anything locally. From here it only needs your final read and a write-capable committer to merge. Thanks again to @goutamadwant for the patient iteration on this one. -- 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]
