SEZ9 commented on PR #12129: URL: https://github.com/apache/seatunnel/pull/12129#issuecomment-5564623071
Thanks @akshar27 — agreed on both points. **CI:** nothing to change on your side; once Actions are enabled on your fork and the retrigger commit is pushed, ping here and I'll re-review on the fresh run. **`PhysicalPlan`-level mock test:** skipping it is the right call for the reasons you gave, and it stays non-blocking. Follow-up or never is fine. Before the fresh pass, could you confirm where the earlier review items stand so I can tick them off against the retriggered head (I don't want to assume anything from this thread alone): 1. `cancelJob()`/`stopJob()` in `PhysicalPlan.java`: with `EnumSet.contains(...)` replacing `ordinal()`, is a null `JobStatus` still failing fast rather than falling through to the CANCELING path? A one-line null guard (or a note on why null is unreachable there) is all I'm after. 2. `NOT_YET_STARTED_STATES`: is the Javadoc now explicit about *why* SCHEDULED is excluded, and is the set wrapped in `Collections.unmodifiableSet`? 3. `JobStatusTest.java`: does the pinning test assert the total count plus each per-index ordinal (so a drift failure names the exact constant), and has the Javadoc been reworded to (a) fix the confusing sentence and (b) make clear it only guards same-build code — a mixed-version Zeta cluster can still hit `ArrayIndexOutOfBoundsException` at the `JobStatus.values()[ordinal]` decode sites? If any of those are already in, a quick "done" per item is plenty; if not, they're small and can ride along with the retrigger commit. Thanks again for the careful work here. <!-- streview-comment:866 --> -- 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]
