SEZ9 commented on issue #12344:
URL: https://github.com/apache/seatunnel/issues/12344#issuecomment-5707559623
One more fact about blast radius, because I initially described this as
blocking two specific pull requests and that understates it.
`all-connectors-it-2` is gated on:
```yaml
all-connectors-it-2:
needs: [ changes, sanity-check ]
if: needs.changes.outputs.api == 'true' || needs.changes.outputs.engine
== 'true'
```
`engine` is set by any change under `seatunnel-engine/**`, and `api` by the
core API modules. So **every pull request that touches the Zeta engine or the
core API currently schedules this job**, and since `testAddFieldWithRestore`
has never once passed (40 real executions, both JDKs, two bases), none of them
can reach a green `Build`. `Build` is the only required status check on
`refs/heads/dev`, so those PRs sit at `mergeStateStatus=BLOCKED` with
`Build=FAILURE` as the sole failing check, regardless of what they change — a
Zeta PR cannot avoid the job by being scoped more narrowly.
That is the practical reason I filed this rather than treating it as
background flakiness. There is nothing a contributor can do from their side:
rerunning does not help, and narrowing the change does not deschedule the job.
I don't know this connector's restore path, so I'm not the right person to
fix it. But if quarantining is preferable to a fix in the short term — e.g.
`@Disabled` on `testAddFieldWithRestore` with a link back to this issue — I'm
happy to send that mechanical PR if a maintainer decides that's the right call.
I'd rather not do it unasked, since disabling a test that may be reporting a
genuine restore-after-schema-change bug is a maintainer's judgement, not mine.
--
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]
