SEPURI-SAI-KRISHNA commented on PR #11724:
URL: https://github.com/apache/seatunnel/pull/11724#issuecomment-5237813520
Both items are closed out.
**Issue 1 (zero-divisor not in the doc entry) — done** in `ff47430b`. Both
`incompatible-changes.md` entries now carry a bullet for it, plus a migration
line for anyone matching on the cause type:
> Dividing by a zero `DECIMAL` now fails with a `TransformException` naming
the operation, where the underlying cause was previously
`java.lang.ArithmeticException("/ by zero")`. The failing expression was
already reported either way, since the SQL engine wraps anything thrown while
evaluating an expression; only the cause type changed. This matches how `MOD`
by zero has always been reported.
**CI — the Windows JDK 8 failure is in `seatunnel-engine-server`, an
unrelated module**, which by your own criterion is enough to clear this. The
log ends with:
```
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test
(default-test) on project seatunnel-engine-server: There are test
failures.
[ERROR] -> [Help 1]
[ERROR] After correcting the problems, you can resume the build with the
command
[ERROR] mvn <args> -rf :seatunnel-engine-server
```
I ran that module's full suite locally on this exact head and it is green:
```
Tests run: 380, Failures: 0, Errors: 0, Skipped: 5
BUILD SUCCESS
```
Three things make a regression from this PR implausible rather than merely
unproven:
1. **`seatunnel-engine-server` does not depend on
`seatunnel-transforms-v2`.** There is no path by which a change to
`ZetaSQLFunction` reaches its tests. The same holds, more strongly, for the
earlier run's failure: that was in `seatunnel-api`, which is *upstream* of
`transforms-v2` — `transforms-v2` depends on `api`, not the reverse, so it
cannot be affected by this diff even in principle.
2. **The failure moves.** Two runs on this branch failed in two different
modules on two different JDK legs — `seatunnel-api` on JDK 11 (`d22a063`),
`seatunnel-engine-server` on JDK 8 (`397315f`). A real regression fails the
same test every time; this doesn't.
3. **The same job passes elsewhere on the same runners.** All four
`unit-test` legs were green on #11697 (`ed97801`) and #11721 (`4393a729`) the
same day.
In each case the other three `unit-test` legs show `cancelled`, which is
matrix fail-fast reacting to the one failure rather than four independent
problems.
For completeness on the earlier round's `kafka-connector-it` question: that
job is flaky across my fork in the same way — over four runs today it failed on
JDK 11 once, JDK 8 twice, and passed on both legs once, on branches that touch
no connector code.
A fresh run for `ff47430b` is under way. I'd rather not present a re-run as
evidence of anything — the local `engine-server` result above is the
substantive check, and the module-dependency argument holds regardless of how
the retry lands.
--
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]
