DanielLeens commented on PR #11077:
URL: https://github.com/apache/seatunnel/pull/11077#issuecomment-5548421140

   ## CI follow-up on the current head (`fe032f17cb38`)
   
   My 2026-09-04T10:41:02Z review noted the fork's `Build` was still in 
progress on this head and said it needed to finish green. It has since 
finished, and the overall `Build` run (`hesam-oxe/seatunnel` run `33856343120`) 
shows `cancelled` with one real failure and two fail-fast cancellations:
   
   - **`rocketmq-connector-it (8, ubuntu-latest)` — failed.** Root cause, 
traced from the actual job log rather than the check-run summary: 
`org.apache.rocketmq.client.exception.MQClientException: CODE: 17 DESC: No 
topic route info in name server for the topic: test_topic_source`, surfacing as 
`RocketMqConnectorException: ErrorCode:[ROCKETMQ-11] Failed to get topic min 
and max topic` in the Flink job managers across all four Flink-version legs 
this IT exercises (1.13.6/1.15.3/1.18.0/1.20.1), plus a `Consume offset should 
be visible for MessageQueue [...]` assertion timeout. This is the RocketMQ 
broker's topic-route metadata not having propagated yet when the job starts 
producing/consuming — a Testcontainers startup-timing race in the shared 
RocketMQ E2E fixture, not anything in this PR's diff.
   - **`kudu-connector-it (8/11, ubuntu-latest)` — cancelled.** Fail-fast 
cascade from the rocketmq failure above, not an independent failure.
   
   This PR's current diff (`seatunnel-api/.../multitablesink/*`, 
`connector-file-base`/`connector-file-hadoop` test files, 
`TaskExecutionService.java`, docs) touches nothing under `connector-rocketmq` 
or its E2E module, so this isn't a regression from this change.
   
   Worth flagging for the record rather than treating as one-off noise: this is 
the same underlying "RocketMQ topic route not ready yet" flake that PR #11458's 
own commit history had to work around locally (`5dd6fa12f "[Fix][E2E] Wait for 
RocketMQ source topic route"`) — it's a standing gap in the shared 
`connector-rocketmq-e2e` fixture that keeps costing unrelated PRs a CI cycle, 
not something specific to this branch. I'm not opening a stabilization PR for 
it myself this round since I haven't yet verified `dev`'s current 
`RocketMqIT`/broker-readiness wait logic closely enough to be confident a 
timeout/retry bump is the real fix rather than papering over a 
container-startup ordering bug; flagging it as a good target for a dedicated 
follow-up rather than guessing here.
   
   **Net for this PR: the CI red is not a blocker for the 
multi-table-sink-writer work.** A job-level rerun of `rocketmq-connector-it (8, 
ubuntu-latest)` (and the two cancelled `kudu-connector-it` legs) should clear 
it. The only other open item remains what my last full review already said: 
getting the branch's diff down to just this feature (the 
`TaskExecutionService.java` hunk is still present) and then a committer 
approval, since mine is comment-only here.
   


-- 
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]

Reply via email to