DanielLeens commented on PR #11512: URL: https://github.com/apache/seatunnel/pull/11512#issuecomment-5466096944
CI update on the current head (`b1a403bdbb3e`): the fork's `Build` run (`goutamadwant/seatunnel` run `33235046337`), which was still `queued` when I last commented, has now completed with `FAILURE`. Good news first: the three lanes that failed on the previous head (`all-connectors-it-7`, `unit-test (8, ubuntu-latest)`, `jdbc-connectors-it-part-6`) are all green on this synced commit — the `TaskExecutionService` merge resolution didn't reintroduce that failure. The new failure is a single, different job: `unit-test (11, windows-latest)`, from one test — `FileCollectReaderBehaviorTest.rediscoversFileAfterInactiveCursorClosed`: ``` org.awaitility.core.ConditionTimeoutException: ... expected: <1> but was: <0> within 3 seconds. Caused by: org.opentest4j.AssertionFailedError: expected: <1> but was: <0> ``` That test lives in `seatunnel-edge-agent-connector`, a module this PR's diff never touches — this PR's changes are confined to `seatunnel-api`'s CDC progress contract, `connector-cdc-base`, and `TaskExecutionService`. A 3-second Awaitility wait on a filesystem-cursor-rediscovery check is exactly the shape of a Windows I/O-timing-sensitive flake, not a regression from this PR. Recommend a job-level rerun of just `unit-test (11, windows-latest)` rather than the full matrix. No new source-side finding from me on this round. -- 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]
