SEPURI-SAI-KRISHNA commented on PR #11937: URL: https://github.com/apache/seatunnel/pull/11937#issuecomment-5488778712
Thanks @DanielLeens, and sorry for the lag. You beat me to the answer, but confirming it formally since you asked for the report: [`33364290269` attempt 2](https://github.com/SEPURI-SAI-KRISHNA/seatunnel/actions/runs/33364290269) concluded **success** at 2026-08-31T16:48:36Z, **83 passed, 10 skipped, 0 failed**, on the same head `e4904ff1e069`. Worth noting for the record that `gh run rerun --failed` did not just retry the failed jobs. Every job in this workflow depends on `Run / changes`, so rerunning that cascaded the whole matrix. Attempt 2 is therefore a full re-validation, not a partial one. All five jobs that were red or cancelled on attempt 1 are green: | Job | Attempt 1 | Attempt 2 | |---|---|---| | `unit-test (8, ubuntu-latest)` | Maven Central `Connection reset` on `io.debezium:debezium-embedded:pom:1.9.8.Final` | [pass](https://github.com/SEPURI-SAI-KRISHNA/seatunnel/actions/runs/33364290269/job/99548206277) | | `unit-test (8, windows-latest)` | `FileCollectReaderBehaviorTest.rediscoversFileAfterInactiveCursorClosed:101` awaitility timeout, in `seatunnel-edge-agent-connector` | [pass](https://github.com/SEPURI-SAI-KRISHNA/seatunnel/actions/runs/33364290269/job/99548206200) | | `jdbc-connectors-it-ddl (8, ubuntu-latest)` | Maven Central `Connection reset` on `maven-jar-plugin:pom:2.4` | [pass](https://github.com/SEPURI-SAI-KRISHNA/seatunnel/actions/runs/33364290269/job/99548206337) | | `paimon-connector-it (11, ubuntu-latest)` | `PaimonWithS3IT`, all 4 tests, `execution timed out after 300000 ms` | [pass](https://github.com/SEPURI-SAI-KRISHNA/seatunnel/actions/runs/33364290269/job/99548206674) | | `rocketmq-connector-it (8, ubuntu-latest)` | cancelled | [pass](https://github.com/SEPURI-SAI-KRISHNA/seatunnel/actions/runs/33364290269/job/99548206301) | Two small notes on attempt 1, since the summary page understated it. It ended with 4 failures plus 1 cancelled rather than 3, and the JDK-8-only pattern did not quite hold: `paimon-connector-it` failed on **JDK 11**. That strengthens rather than weakens the noise conclusion, though, because that one is a flake we already track. All four `PaimonWithS3IT` tests died with an assertion message that carries its own tracking issue inline: ``` Job /fake_to_paimon_with_s3_with_privilege.conf did not return within 5 minutes. The cluster may have reached a terminal state without the seatunnel.sh client observing it - see https://github.com/apache/seatunnel/issues/11679 ``` That is #11679, still open, and the two privilege-check cases it names (`privilegeEnabledPaimonSourceAuthorized`, `privilegeEnabledPaimonSourceUnAuthorized`) are exactly its scenario. It passed on the rerun, which is the expected behaviour for that flake. The other three were not test failures at all: both `Connection reset` jobs died during Maven dependency resolution before reaching surefire, and the Windows one was a 3 second awaitility timeout in `seatunnel-edge-agent-connector`, a module this PR does not touch. `seatunnel-transforms-v2` did not fail anywhere in either attempt. **On the stale review state:** I do not think there is anything to dismiss. GitHub's sidebar uses the latest review per reviewer, and `latestReviews` on this PR currently returns only two nodes, `DanielLeens: COMMENTED` and `goutamadwant: APPROVED`. The 2026-08-22 `CHANGES_REQUESTED` was already superseded by @goutamadwant's own 08-29 `APPROVED`, so it is not being counted. What actually blocks the merge is `reviewDecision: REVIEW_REQUIRED` with `mergeStateStatus: BLOCKED`, meaning a required review is still outstanding rather than a negative one being stuck. So this needs a committer to review, not a dismissal. **On the drift:** `dev` has moved again since your note. `compare/dev...e4904ff1e` now reports `ahead_by=3, behind_by=5`; the branch itself has not moved since the 06:27 UTC force-push. The five commits are `1d18735bd` (#12013), `f0046a002` (#11649), `b4158f01d` (#11991), `f4840f1c7` (#11886) and `5dbfb374f` (#11985). Of those, only `f0046a002` touches a file this PR also edits (`docs/en/introduction/concepts/incompatible-changes.md`). Happy to sync again before merge if a committer would like it; it just needs the same conflict resolution in that one file that the last rebase already handled cleanly. Otherwise I would rather leave the head stable so the green run above stays the one being merged. -- 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]
