Interface KafkaOptions

Kafka bootstrap brokers.

Injected Kafka factory.

Kafka client ID (default: 'messaging-client').

Default consumer group name.

Optional logger. Reads a consumer whose consumer.run() rejects — kafkajs's crash handler rethrows a disconnect that fails — which would otherwise be an unhandled rejection. Fresh-group initialization failures use warn when supplied, else error, and name the topic and group. The subscription remains active.

Publish bound in ms, default 15000; 0 disables it. A timeout may still deliver.

Topic every request-reply response is published to and read back from.

Kafka topics are durable cluster resources and this broker creates none, so the topic must already exist (or auto.create.topics.enable must be on). The same holds for every SUBSCRIBED topic: on a broker that does not auto-create, subscribing a topic that does not exist makes subscribe() (and so start() for a declared subscription) reject, once the retry budget is spent, with KafkaTopicUnavailableError naming the topic and the consumer group. Each broker instance reads it under its own consumer group, so every instance sees every reply and discards those it did not originate — give a high-traffic service its own reply topic to bound that fan-out.

Retry budget (M101b). Forwarded verbatim to new Kafka({ retry }), where kafkajs uses it for its own retries; and read by the broker to retry a subscription whose topic the Kafka broker reports unknown.

kafkajs does not retry UNKNOWN_TOPIC_OR_PARTITION (its metadata retrier gives up on every error but LEADER_NOT_AVAILABLE), and a KRaft broker with auto.create.topics.enable answers exactly that to the request that creates the topic — measured on Kafka 4.0, the next attempt succeeds. So subscribe() retries that one error with exponential backoff: retries attempts after the first, waiting initialRetryTime and growing by multiplier up to maxRetryTime — kafkajs's defaults, 5 / 300 ms / 2 / 30 s, about 9 s in all. A topic still unknown after that rejects with KafkaTopicUnavailableError; retries: 0 names it at once. Every field is validated at construction, factor (kafkajs's jitter) included, held to [0, 1]. The forwarding to kafkajs is skipped when client is injected (the application built that Kafka); the subscribe retry applies either way.