C0urante commented on PR #13284: URL: https://github.com/apache/kafka/pull/13284#issuecomment-1574216434
@divijvaidya No worries about the delay--looks like we're both guilty on that front 😅 I took at look at this and the issue is that the `MirrorCheckpointConnector` and `MirrorSourceConnector` instances are generating empty lists of task configs, which makes since since the former never generates tasks during these tests and the latter only generates tasks once a to-be-mirrored topic on the upstream cluster is created, which currently takes place only after our startup check has finished. Correct me if I'm wrong: the idea here is to add granularity to test failure messages so that we can differentiate between MM2 startup issues (caused by lagginess or connector/task failures) and issues with the actual replication logic performed by MM2. If that's the case, do you think it might make sense to do the following? - Alter the"await startup" logic to fail immediately if it detects any failed connectors or tasks - Alter the "await startup" logic to operate on a per-connector-type basis, and selectively await the startup of different connector types at different points in the test (e.g., we could await the startup of the heartbeat connector in any place where we currently call `waitForMirrorMakersToStart`, but only await the startup of the source connector and its tasks once we've created a to-be-replicated topic on the upstream cluster) -- 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: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
