Release 3.6.18

Released October 12, 2026. This release improves Kafka correctness under failover and storage pressure, reduces storage-path pauses, closes authorization gaps, and fixes dashboard reliability and accessibility issues. Read the upgrade guidance before changing a production cluster. The complete change list is in the official server release.

Artifacts

Before you upgrade

• Back up every data directory. This version writes a segment seal marker that older servers do not understand safely. Do not point an older server at a data directory after 3.6.18 has written it.
• Finish a rolling upgrade before deleting or recreating Kafka topics. New topic-deletion records and committed offsets use offset-log format version 2. Older servers cannot take over affected consumer groups and are no longer rollback targets for that data.
• When upgrading from 3.6.16 or earlier, Kafka topics without their own retention.ms now retain data for 7 days. Set CONNECTORS_KAFKA_LOG_RETENTION_MS=-1 on every server before upgrading if those topics must retain records indefinitely. The value 0 is now rejected at boot.
• Mutual Transport Layer Security clients now use the certificate's full distinguished name as their Kafka principal. Review authorization rules that match only the common name.
• Kafka cluster administration requires a principal listed in CONNECTORS_KAFKA_SUPER_USERS when authorization is enabled. Review broad write grants and any settings created while running the first 3.6.18 release candidate.
• Review existing TUNING_*, CONNECTORS_MQTT_*, Model Context Protocol, and agent protocol environment variables. Variables that were previously ignored now take effect, and invalid values stop configuration loading instead of resetting it to defaults.

Changes

• Storage checkpoints and segment sealing leave the publish path, reducing long-tail latency. Set STORE_NEXT_ASYNC_CHECKPOINT=false and restart to restore the previous checkpoint locking while the new default awaits cloud acceptance testing.
• Kafka topic deletion removes committed offsets, blocks stale commits from restoring a deleted topic, and cleans up partitions recreated by producers during deletion.
• Kafka produce requests account for time spent waiting behind throttling or serialized requests. Responses now reserve 2 seconds inside the client's timeout, and expired requests store nothing.
• Storage-pressure handling retries ordered writes for up to 5 seconds. Synchronous Events Store and Queue sends now wait up to 6 seconds for persistence acknowledgement.
• Authorization now protects reserved feeds, internal channel operations, agent gateway calls, dashboard settings, and Kafka cluster administration more narrowly.
• Kafka adds stronger consumer-group reconciliation, share-group correctness, mutable access-control lists, quotas, credential administration, incremental fetch sessions, and more complete metrics.
• Compaction uses bounded memory, sealed segments no longer keep files open, and stale transaction markers are reclaimed more aggressively.
• Dashboard fixes cover session restore, sign-out, monitor reconnection, error reporting, navigation encoding, narrow layouts, keyboard access, and screen-reader semantics.

Known limits

• Cloud acceptance is still pending for asynchronous checkpoints, segment sealing outside the publish path, and byte-bounded retention. Keep the checkpoint kill switch available.
• Deleting a topic with 4,096 partitions took 60 to 100 seconds before the deletion changes. The final build has not been remeasured.
• The final build did not receive the 4-hour retention soak. A 60-minute earlier run showed stable segment file usage and much lower transaction-marker memory, but the long-run bound remains unverified.
• Recovery after an unclean node reboot took 110 to 145 seconds. Producer throughput stayed between 8% and 20% for about 85 seconds while producer state warmed.
• Rebuilding a server after disk loss reached Ready in about 29 minutes under 300,000 messages per second. Full synchronization took 924 seconds, exceeding the 900-second target.
• Under a 100-millisecond, 2% packet-loss link, an earlier build answered 16 produce requests after the client's 30-second timeout. The cause is fixed here, but the fault test was not repeated on the final build and throughput still collapses during that fault.
• With one server limited to 50 megabytes per second of disk throughput, affected partitions can take about 10 seconds to answer before leadership moves. Keep producer delivery.timeout.ms at 60 seconds or longer. The leadership fix was not repeated on the final build.
• After a 60-second leader isolation, one earlier run needed 68 seconds to return to full synchronization. Kafka certification and the byte-bounded replication-log acceptance run were not repeated for this release.