SEZ9 commented on issue #12332: URL: https://github.com/apache/seatunnel/issues/12332#issuecomment-5723993626
Thanks for correcting the mechanism here rather than editing the body silently. I follow the argument: `examineConsumeStats(group, topic)` resolves its route only from `MixAll.getRetryTopic(group)`, the requested topic is just a parameter to the later broker call (which surfaces as `MQBrokerException`), and `getTopicRouteInfoFromNameServer` throws rather than returning null on code 17. So the `TOPIC_NOT_EXIST` branch in `currentOffsets` means "no route for `%RETRY%<group>`", not "the data topic is missing". That doesn't weaken the original point: `currentOffsets` still maps a failed lookup to an empty map, and `CONSUME_FROM_GROUP_OFFSETS` still reads that as a cold start and rewinds. I also agree with the two retractions. With `setPartitionStartOffset()` running once per job start right after `fetchPendingPartitionSplit()` in the same synchronized block, and `offsetTopics` failing first on a broker-wide route sweep, the exposure is the narrow window you describe. Rare, but the outcome is the same silent full re-delivery, so it still needs fixing. Two things I'd like to understand for the fix: 1. Given that code 17 from this call only ever refers to the retry topic route, what axis should the fix use to separate a genuine cold start from a transient lookup failure, and what does it do in that branch (fail the job, retry the lookup, or something else)? 2. Does the fix PR's description reflect the corrected mechanism (`%RETRY%<group>` rather than the data topic), so reviewers there aren't working from the old model? On the E2E test, agreed: a test that races the broker heartbeat to keep the route absent is exactly the flakiness we don't want, so a unit-level test of the `currentOffsets` branch is sufficient for me. <!-- streview-comment:1121 --> -- 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]
