[GitHub] [kafka] C0urante commented on a change in pull request #8928: KAFKA-10192: Wait for REST API to become available before testing blocked connectors

[GitBox <gi...@apache.org>]

C0urante commented on a change in pull request #8928:
URL: https://github.com/apache/kafka/pull/8928#discussion_r449789091



##########
File path: connect/runtime/src/test/java/org/apache/kafka/connect/integration/BlockingConnectorTest.java
##########
@@ -76,6 +78,15 @@ public void setup() {
 
         // start the clusters
         connect.start();
+
+        // wait for the Connect REST API to become available. necessary because of the reduced REST
+        // request timeout; otherwise, we may get an unexpected 500 with our first real REST request
+        // if the worker is still getting on its feet.
+        waitForCondition(

Review comment:
       That won't quite buy us what we need. The litmus test for a worker being available with that call is that its [root resource returns a valid ServerInfo response](https://github.com/apache/kafka/blob/72042f26aff396ed85d02e7e312fd07ea2cc7617/connect/runtime/src/test/java/org/apache/kafka/connect/util/clusters/EmbeddedConnectCluster.java#L269-L270), but this doesn't guarantee that the worker has completed startup (reading to the end of internal topics, specifically) and so calls to the REST API that have to be handled in the `DistributedHerder::tick` method may still block and, because of the reduced timeouts for this test, fail.
   
   This isn't a great solution but as far as I can tell there's no official way to determine if a worker has completed startup or not via the REST API, so issuing an info request for a non-existent connector is used instead.




----------------------------------------------------------------
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.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org