CAMEL-23430: Fix flaky tests in camel-kafka

[gnodet]

CAMEL-23430

Fix two flaky tests in camel-kafka:

KafkaConsumerAutoInstResumeRouteStrategyIT.testOffsetIsBeingChecked:

• Producer was never flushed or closed after sending messages — messages may not have been delivered to Kafka when the test starts consuming
• mock.assertIsSatisfied() was called without any wait timeout — the assertion checked immediately before the route had time to consume and process messages
• Fix: use try-with-resources for the producer with an explicit flush, and use Awaitility to wait for the mock assertion

KafkaIdempotentRepositoryEagerIT.createRepositoryTopic (via KafkaTestUtil.createTopic):

• The describeTopics() future had only a 5-second timeout, which is too tight when the Kafka broker is still warming up
• The AdminClient was never closed, leaking resources
• Fix: increase timeout to 30 seconds and use try-with-resources for the AdminClient

[github-actions]

🌟 Thank you for your contribution to the Apache Camel project! 🌟
🤖 CI automation will test this PR automatically.

🐫 Apache Camel Committers, please review the following items:

• First-time contributors require MANUAL approval for the GitHub Actions to run
• You can use the command /component-test (camel-)component-name1 (camel-)component-name2.. to request a test from the test bot although they are normally detected and executed by CI.
• You can label PRs using skip-tests and test-dependents to fine-tune the checks executed by this PR.
• Build and test logs are available in the summary page. Only Apache Camel committers have access to the summary.

⚠️ Be careful when sharing logs. Review their contents before sharing them publicly.

[github-actions]

🧪 CI tested the following changed modules:

• components/camel-kafka

⚠️ Some tests are disabled on GitHub Actions (@DisabledIfSystemProperty(named = "ci.env.name")) and require manual verification:

• components/camel-kafka: 3 test(s) disabled on GitHub Actions

All tested modules (8 modules)

• Camel :: JBang :: MCP
• Camel :: JBang :: Plugin :: Route Parser
• Camel :: JBang :: Plugin :: TUI
• Camel :: JBang :: Plugin :: Validate
• Camel :: Kafka
• Camel :: Launcher :: Container
• Camel :: YAML DSL :: Validator
• Camel :: YAML DSL :: Validator Maven Plugin

---

⚙️ View full build and test results

[apupier]

I do not think that chaging the tiemout will change anything. Based on the stack trace, I understand that the answer is returned as soon as it is possible and i tis throwing:

.UnknownTopicOrPartitionException: This server does not host this topic-partition.

In case, it is a matter of time that the topic are not created, we need to use an await() and check several times if there are some topics. (which we do not know if it is a matter of time or if there is a differnt problem that can prevent the creation of the topics from time to time)

[gnodet]

Claude Code on behalf of Guillaume Nodet

Good point, you're right that the exception is UnknownTopicOrPartitionException which returns immediately rather than timing out. I've replaced the simple timeout increase with Awaitility polling: it now retries describeTopics every second for up to 30 seconds, using ignoreExceptions() to treat the UnknownTopicOrPartitionException as a "not yet" signal.

[apupier]

I think we need to be slightly lower than the timeout of the test to benefit from this assertion to fail with precise message instead of the genric timeout for the test.

[gnodet]

Claude Code on behalf of Guillaume Nodet

Good catch — lowered the Awaitility timeout to 25 seconds (vs the 30s @Timeout) so the assertion failure message is precise rather than a generic JUnit timeout.