SEZ9 commented on PR #12079: URL: https://github.com/apache/seatunnel/pull/12079#issuecomment-5852071099
Thanks for going through the `d8045271fcf6 -> 3df75448c` diff point by point — that is the format I was hoping for. A few things before I can close anything out: **F8 / F5** — The description of `validateTransform` reading IDs from the scheduled transform, and of a single `TransformDependencyScheduler.scheduleTransforms` with `DryRunConnectValidator.scheduleTransforms` reduced to an exception-translating wrapper, sounds like the right shape. I still need to confirm it against the actual changed files rather than the comment, so I'll leave these open until I've looked at the diff itself. **F7** — As you note, the `incompatible-changes.md` entries did not change in this commit, so there's nothing in the diff under review for me to check here. I'll verify the entries at `3df75448c` directly before marking this resolved. **F1** — The reasoning on `waitingByInputId.remove(transform.outputId)` makes sense to me: emptying the entry on the first producer means a second producer of the same output ID cannot decrement `unresolvedInputCount` again. Your comment appears to be cut off right at "Tests at the current head", though, so I can't see which test covers this. Could you post the test class/method name(s) that exercise the duplicate-output-ID case (two transforms both defaulting to `DEFAULT_ID`, or an explicit duplicate `plugin_output`, feeding a multi-input dependent)? If there isn't one yet, please add it — this is the regression I'd most want guarded. **Still missing** — The comment says "all seven", but I only see F8, F7, F5 and F1. I still need current-head evidence for: - **F2** — multi-transform `findLast` fallback when the last transform omits `plugin_input` - **F3** — scheduling and validation using the same ID source (this may be covered by the F8 change, but please confirm explicitly) - **F4** — multi-transform jobs that previously relied on the implicit last-schema fallback - **F6** — single-transform self-cycle no longer slipping through the legacy fallback File and line at `3df75448c`, same as above, is perfect. Once those are in I'll do a full pass against the diff. <!-- streview-comment:1349 --> -- 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]
