davidzollo opened a new pull request, #12115: URL: https://github.com/apache/seatunnel/pull/12115
## What does this PR do? `RocketMqIT#waitForTopicRoute` confirmed a topic's route through the test producer's `fetchPublishMessageQueues()`, which can be answered from the producer's own route cache (primed by `createTopic()` against the broker) before the **name server** has published the route. The connector resolves routes with a fresh admin client (`RocketMqAdminUtil#offsetTopics` → `DefaultMQAdminExt#examineTopicStats`), so a job could still start and fail with `ROCKETMQ-11` ← `MQClientException CODE: 17 No topic route info in name server for the topic` right after the wait returned. This additionally requires the route to be visible through the connector's own resolution path within the same 1-minute budget. Nothing is relaxed — one stronger readiness condition is added. ## Why is this needed? Seen repeatedly on unrelated PRs (#11503, #11077, #12099): hundreds of `CODE: 17` / `ROCKETMQ-11` errors per run taking down most of `RocketMqIT`, while the sibling JDK leg of the same run passed on identical code. The earlier producer-side wait (#12050) narrowed but did not close the gap. ## Does this PR introduce any user-facing change? No. Test-only. ## How was this patch tested? Test-only; the added check uses the same `RocketMqAdminUtil.offsetTopics(newConfiguration(), …)` call the test already relies on for consuming, so it exercises exactly the code path that was failing. 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- 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]
