SEPURI-SAI-KRISHNA commented on issue #9940: URL: https://github.com/apache/seatunnel/issues/9940#issuecomment-5711579179
@SEZ9 the distinction you asked for in point 3 is built: #12349 is open with green CI. One correction first, since my comment above stated the mechanism wrongly and you have restated it since. `examineConsumeStats` resolves its route solely from the group's `%RETRY%` topic and never from the requested topic, so the code 17 is always `%RETRY%` plus the group name. @DanielLeens caught this on #12349. I have put the full correction with the bytecode references on #12332 rather than filling up this thread. That changes what is worth asking @heye1005 for. "Any `CODE: 17` warnings around startup" will not separate the cases, because a broker wide outage produces those too and would have failed the job earlier in `offsetTopics`. The narrower questions are: 1. does the `No topic route info` message name `%RETRY%` plus the consumer group, rather than the data topic 2. was the data topic's own route healthy at that same moment 3. did the broker still show committed offsets for `track_report_group` The retry topic named and the data topic healthy is the path #12332 describes. Both missing together is a broker or name server outage, which is a different problem and would not rewind. I should also withdraw something. My earlier comment argued a job "only has to be unlucky once" because discovery re-enters the lookup. It does not: `setPartitionStartOffset()` is called once, from `run():180`, and `discoverySplits()` never calls it. The exposure is narrower than I implied there. -- 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]
