Kafma v1.2.1
Kafma v1.2.1 is a maintenance release focused on consumer groups and cluster reliability. Groups on Kafka's new consumer protocol now show their real state, consumer lag includes records held back by unfinished transactions, and an offline partition no longer affects healthy topics. The Console producer also shows where each send landed.
Read consumer groups on the new consumer protocol
Kafma now shows the real state, members, partition assignment, and assignor of consumer groups that use group.protocol=consumer (KIP-848, Kafka 4.0 and later), with a KIP-848 badge. This applies to the group list, group details, a topic's consumers, and Watch Group. Before, these groups showed as Dead with no members, and Kafma offered Reset Offsets and Delete while they were running.
- Groups that are assigning or reconciling partitions show as Rebalancing.
- If Kafma can't read a group's state, the group shows as Unknown, and resetting offsets or deleting the group stays unavailable.
- Share groups and Kafka Streams groups on the new streams protocol aren't supported yet, so they no longer appear in the list.
Count lag behind unfinished transactions
Consumer lag now counts to the end of the log (the high watermark), matching kafka-consumer-groups.sh. Before, a group stuck behind an unfinished transaction could show a lag of 0 while records built up behind it. Message counts in the Topics list and offset ranges in topic details also count to the end of the log.
Once Kafma has seen an unfinished transaction block a partition for 10 seconds, Watch Group and group details show how many offsets it holds back, such as 4 blocked by a transaction. Hover over the label to see the offset where the transaction starts and how long Kafma has seen it blocking.

Resetting offsets to Latest still stops at an unfinished transaction, so its records aren't skipped if it commits. The Reset Offsets dialog now notes when an unfinished transaction stops the reset.
Stay connected when a partition is offline
A partition without a leader, for example while a broker is down, no longer stops Kafma from connecting or working with healthy topics. Actions that need the offline partition may still fail until it's back.
If a topic you've opened in Kafma is deleted elsewhere, for example with the Kafka CLI, other actions on the cluster no longer fail with UNKNOWN_TOPIC_OR_PARTITION.
See where your sends landed
After you produce, a receipt line above the producer shows where the send landed and when: the partition and offset for a single record, such as Sent to P1 · offset 12, or the number of records sent by a batch, Loop, or File run. The receipt stays visible when the producer is collapsed. When a File run finishes, the file is ready to send again.
In a snapshot, the receipt also notes that new records don't appear in the list, and offers Switch to Live.
On Production clusters, the production reminder now shares the receipt line instead of adding a second strip above the form. Produce and Run Loop keep the reminder in their tooltip.

Other improvements and fixes
- When a connector configuration uses config provider references such as
${file:/etc/kafka/secrets.properties:password}, a failed create or edit no longer copies Kafka Connect's error into Activity Logs. Kafka Connect resolves the references before validating, so its errors can include the resolved secret values. Kafma still shows the error so you can fix the configuration. - On KRaft clusters, the Brokers page now marks the active controller. Before, it marked a random broker that could change between refreshes. A controller that runs separately from the brokers is shown by its node ID.
- The Brokers page keeps the Divergent tab selected across refreshes and shows settings without a value as
(empty). - Brokers that report no log directories show storage as unknown instead of 0 B, and the broker menu scrolls when there are many brokers.
- Clearing a topic no longer skips partitions that were added outside Kafma shortly before.
- When Kafma can't reach a Kafka Connect cluster, the error stays on screen while you retry, with Edit Connection and Retry as on a cluster connection error.