[jira] [Created] (KAFKA-14855) Harden integration testing logic for asserting that a connector is deleted

["Chris Egerton (Jira)" <ji...@apache.org>]

Chris Egerton created KAFKA-14855:
-------------------------------------

             Summary: Harden integration testing logic for asserting that a connector is deleted
                 Key: KAFKA-14855
                 URL: https://issues.apache.org/jira/browse/KAFKA-14855
             Project: Kafka
          Issue Type: Improvement
          Components: KafkaConnect
            Reporter: Chris Egerton


In the Connect embedded integration testing framework, the [EmbeddedConnectClusterAssertions::assertConnectorAndTasksAreStopped method|https://github.com/apache/kafka/blob/31440b00f3ed8de65f368d41d6cf2efb07ca4a5c/connect/runtime/src/test/java/org/apache/kafka/connect/util/clusters/EmbeddedConnectClusterAssertions.java#L411-L428] is used in several places to verify that a connector has been deleted. (This method may be renamed in an upcoming PR to something like {{{}assertConnectorAndTasksAreNotRunning{}}}, but apart from that, its usage and semantics will remain unchanged.) However, the [underlying logic for that assertion|https://github.com/apache/kafka/blob/31440b00f3ed8de65f368d41d6cf2efb07ca4a5c/connect/runtime/src/test/java/org/apache/kafka/connect/util/clusters/EmbeddedConnectClusterAssertions.java#L430-L451] doesn't strictly check for deletion (which can be done by verifying that the connector and its tasks no longer appear in the REST API at all), since it also allows for the Connector or tasks to appear in the REST API, but with a state that is not {{{}RUNNING{}}}.

This constraint is a bit too lax and may be silently masking issues with our shutdown logic for to-be-deleted connectors. We should try to narrow the criteria for that method so that it fails if the Connector or any of its tasks still appear in the REST API, even with a non-{{{}RUNNING{}}} state.

However, we should also be careful to ensure that current uses of that method are not relying on its semantics. If, for some reason, a test case requires the existing semantics, we should evaluate whether it's necessary to continue to rely on those semantics, and if so, probably preserve the existing method so that it can be used wherever applicable (but rewrite all other tests to use the new, stricter method).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)