[ 
https://issues.apache.org/jira/browse/KAFKA-16943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17856531#comment-17856531
 ] 

Chris Egerton commented on KAFKA-16943:
---------------------------------------

[~ksolves.kafka] the idea here isn't to assert that no workers have started 
after a given timeout, it's to assert that one or more workers has attempted, 
failed, and aborted startup. We don't want to just wait for 30 seconds, see 
that no workers have started up, and then call that good enough, since startup 
may take longer than 30 seconds on our CI infrastructure (which can be pretty 
slow), and if startup does fail before the 30 seconds are up, it still forces 
us to wait that long, adding bloat to test runtime.

> Synchronously verify Connect worker startup failure in 
> InternalTopicsIntegrationTest
> ------------------------------------------------------------------------------------
>
>                 Key: KAFKA-16943
>                 URL: https://issues.apache.org/jira/browse/KAFKA-16943
>             Project: Kafka
>          Issue Type: Improvement
>          Components: connect
>            Reporter: Chris Egerton
>            Priority: Minor
>              Labels: newbie
>         Attachments: code-diff.png
>
>
> Created after PR discussion 
> [here|https://github.com/apache/kafka/pull/16288#discussion_r1636615220].
> In some of our integration tests, we want to verify that a Connect worker 
> cannot start under poor conditions (such as when its internal topics do not 
> yet exist and it is configured to create them with a higher replication 
> factor than the number of available brokers, or when its internal topics 
> already exist but they do not have the compaction cleanup policy).
> This is currently not possible, and presents a possible gap in testing 
> coverage, especially for the test cases 
> {{testFailToCreateInternalTopicsWithMoreReplicasThanBrokers}} and 
> {{{}testFailToStartWhenInternalTopicsAreNotCompacted{}}}. It'd be nice if we 
> could have some way of synchronously awaiting the completion or failure of 
> worker startup in our integration tests in order to guarantee that worker 
> startup fails under sufficiently adverse conditions.



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

Reply via email to