SEPURI-SAI-KRISHNA commented on PR #12909:
URL: https://github.com/apache/seatunnel/pull/12909#issuecomment-6282200750
The `Build` check here is red, and none of it comes from this change.
Details so nobody has to re-derive them.
Fork run `39276501805` on head `b4c5a0ee4` is 27 success, 39 skipped, 4
failure. The four failures are exactly the four `unit-test` legs, `(11,
ubuntu)`, `(17, ubuntu)`, `(11, windows)` and `(17, windows)`. Every other job,
including the ones whose path filters reach `connector-file-base`, passed.
All four legs die at the same place, in `connector-jdbc`, which this PR does
not touch:
```
JdbcOptionRuleCompletenessTest.testSinkRuleDeclaresAllSinkOptions
OptionValidationException: Connector 'Jdbc' has unknown option keys:
[numeric_special_value_as_null]
```
This is a pre-existing break on `dev`, already tracked as #12874 with the
fix in #12875. The mechanism is a timing collision between two merged PRs:
- #12800 (merged 2026-10-16 18:12Z) added `JdbcOptionRuleCompletenessTest`,
which reflects over `JdbcSinkOptions` and therefore over everything it inherits
from `JdbcCommonOptions`.
- #12792 (merged 2026-10-18 14:38Z) added `numeric_special_value_as_null` to
`JdbcCommonOptions` and declared it only in the source rule.
I checked this against the current `dev` head rather than a local copy:
`JdbcSinkFactory` references `NUMERIC_SPECIAL_VALUE_AS_NULL` zero times,
`JdbcConnectionConfig` reads it three times, and the guard test is present with
no exclusion. So `dev` has been red on `unit-test` since 2026-10-18 14:38Z.
I also reproduced it locally on a tree carrying no JDBC changes at all, and
the identical four-leg failure appears on my unrelated #12899, which is a
`transforms-v2` change. Two independent branches failing the same step in the
same module is what you would expect from a base break rather than from either
diff.
This PR is four files: `OrcWriteStrategy.java`, `OrcWriteStrategyTest.java`
and the two `incompatible-changes.md` docs. Nothing in it reaches
`connector-jdbc`.
No rerun here can go green until #12875 merges, so I am leaving the badge as
it is rather than burning runner time. Once #12875 lands I will sync and rerun,
and I am happy to do that sooner if a reviewer prefers.
--
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]
