SEPURI-SAI-KRISHNA commented on PR #12323: URL: https://github.com/apache/seatunnel/pull/12323#issuecomment-5678932572
Thanks for the review and for reading the CI before I got to it. Agreed on the diagnosis, and I will retrigger the job. Two things from the logs first, because I think this run is better news than one red leg suggests. **The route failures are gone.** I grepped the full log of both legs for the signatures this PR targets: | Signature | Before (2026-09-14 scheduled run) | This run | |---|---|---| | `generateTestData:467 ยป MQClientException` | 31 | 0 | | `ROCKETMQ-11 Failed to get topic min and max topic` (enumerator path) | present | 0 | `rocketmq-connector-it (8, ubuntu-latest)` passed outright: `Tests run: 87, Failures: 0, Errors: 0`. That is the leg that failed 6 of the 12 scheduled runs I sampled, so a clean pass there is the single most useful data point available this early. The JDK 11 leg is `Tests run: 87, Failures: 0, Errors: 7`, and all 7 are the one signature you quoted. Note there are no longer any `Failures`, only the `waitConsumedOffsetsSynced` errors. For completeness, `No topic route info in name server` does still appear twice in the JDK 11 log, and I checked rather than assume: both are the same event logged twice, once on the container stream and once in captured stderr, as a client-side `WARN` for `test_topic_restore_output_<uuid>`, a sink output topic. `testSourceRocketMqRestore` passed in that run, so it is benign log noise rather than a failure. **On the remaining failure.** You are right that it is untouched by this diff and pre-existing. I would add that it is not incidental: I called it out in #12322 as the secondary symptom, 10 of the 61 bad results in the 2026-09-14 run, and the in-file comment records that the window was already raised from 30s to 60s after an earlier occurrence. It timed out at 60s again on 09-14 and has now done so again here, which suggests the ceiling is not the real constraint and another bump would not settle it either. So a rerun may well come back green, but that is a coin flip rather than a fix. I would rather keep this PR to the route problem it is scoped to, and open a separate one for `waitConsumedOffsetsSynced` on the broker-side offset-commit visibility path, where the question is why per-queue commit visibility does not converge rather than how long to wait for it. Happy to take that on as a follow-up unless you would prefer it folded in here. Retriggering the failed job now. -- 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]
