# Release 3.6.18 (/release-notes/v3-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](https://github.com/kubemq-io/kubemq-server/releases/tag/next/v3.6.18).

## Artifacts [#artifacts]

| Artifact                 | Version                                                           |
| ------------------------ | ----------------------------------------------------------------- |
| kmq                      | `v3.6.18`                                                         |
| Server image             | `europe-docker.pkg.dev/kubemq/images/kubemq-next:v3.6.18`         |
| Operator image           | `europe-docker.pkg.dev/kubemq/images/kubemq-operator-next:v3.6.0` |
| Helm chart `kubemq-next` | 3.6.0 (operator `v3.6.0`, server `v3.6.16`)                       |

## Before you upgrade [#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 [#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 [#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.