DanielLeens commented on PR #11757: URL: https://github.com/apache/seatunnel/pull/11757#issuecomment-5551506571
CI-status update on the current head, `c65e82e`. **No source-level re-review needed on `c65e82e` itself.** I diffed it against `4336d46` (the commit I approved) directly: the only change is a Javadoc re-wrap on `testStaleFailedTaskDoneDoesNotCleanupNewerGenerationResources`'s comment (line width only, no code, no test-body change). My APPROVED conclusion from `4336d46` stands unchanged — this isn't a new code version that needs a fresh Section 1-4 write-up. **What does need an update: the `Build` fact.** When I approved `4336d46`, `Build` was still queued/in-progress with no completed signal either way, so I said I was "waiting on the fresh Build run" without presuming the outcome. That run has since completed on `c65e82e`, and it's `failure` — I want to make sure that doesn't sit on the PR looking like an open question. I dereferenced the actual failing job on the fork (`waterWang/seatunnel` run `33945211319`): `Run / all-connectors-it-2 (8, ubuntu-latest)`, specifically `CouchbaseIT.testFakeSourceToCouchbaseSink` — a `WaitUntilReady timed out in stage WAIT_FOR_CONFIG` / KV-service authentication timeout against the Couchbase test container. That module has nothing to do with this PR's diff (`TaskExecutionService`/stale-taskDone restore-generation handling); Couchbase E2E has a known container-bootstrap-instability history in this repo, and the specific startup-retry hardening for it (#11845, "Retry Couchbase container startup and capture server logs") already merged into `dev` on 2026-08-18 — before this branch's current base. I confirmed that fix commit (`449db4e`) is already an ancestor of this PR's head, so this isn't a case where syncing `dev` would help: the known mitigation is already present, and what's failing today is a different symptom (an auth/config-readiness timeout rather than the connection-reset pattern #11845 targeted) of the same underlying container-startup flakiness, not something this PR's sync state can fix. **Bottom line:** this failure is unrelated to the PR's changes and isn't something a `dev` sync would resolve — please just rerun the failed job (or the full `Build`) at your convenience. My technical review remains APPROVED; I'm not asking for any new PR change here, just flagging that the `Build [failure]` currently showing on this head is an environment flake, not a new blocker. (Upstream note for the record: this branch is currently `diverged` from `dev`, `behind_by=61`/`ahead_by=9`. That's queue metadata, not something I'm asking you to act on — it isn't the cause of today's CI failure, and `mergeable=true` with no reported conflicts.) -- 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]
