KAFKA-20395: Support unregistering controllers by kevin-wu24 · Pull Request #22191 · apache/kafka

kevin-wu24 · 2026-05-01T17:47:57Z

What Changed

Introduce UnregisterControllerRequest and
UnregisterControllerResponse RPC schemas
Introduce Admin#unregisterController interface, which the
kafka-cluster and kafka-metadata-quorum tools call via the
AdminClient to unregister a controller
Add controller-side handling for UnregisterControllerRequest
Introduce UnregisterControllerRecord metadata record schema + new
MetadataVersion IBP_4_4_IV2 to support this feature
Add handling for replaying the UnregisterControllerRecord on the
active controller and in the Cluster/MetadataDelta to remove
unregistered controllers from the MetadataImage
Add the kafka-cluster unregister-controller CLI command
Add the --unregister flag to the kafka-metadata-quorum remove-controller command

Testing

Unit testing for CLI changes, controller-side changes, and AdminClient
changes
Integration tests in KRaftClusterTest

Reviewers: Jun Rao junrao@gmail.com, Chetan Koneru
(github:ChetanKoneru), Paolo Patierno ppatierno@live.com

…adata-quorum tool error handling

github-actions · 2026-05-09T04:13:57Z

A label of 'needs-attention' was automatically added to this PR in order to raise the
attention of the committers. Once this issue has been triaged, the triage label
should be removed to prevent this automation from happening again.

github-actions · 2026-05-14T04:23:57Z

A label of 'needs-attention' was automatically added to this PR in order to raise the
attention of the committers. Once this issue has been triaged, the triage label
should be removed to prevent this automation from happening again.

github-actions · 2026-05-16T04:17:56Z

A label of 'needs-attention' was automatically added to this PR in order to raise the
attention of the committers. Once this issue has been triaged, the triage label
should be removed to prevent this automation from happening again.

github-actions · 2026-05-20T04:31:50Z

A label of 'needs-attention' was automatically added to this PR in order to raise the
attention of the committers. Once this issue has been triaged, the triage label
should be removed to prevent this automation from happening again.

ahuang98

Thanks Kevin!

ahuang98 · 2026-05-22T05:25:59Z

+    private void runUnregisterScenario(
+        AdminClientUnitTestEnv env,
+        ApiKeys apiKey,
+        Function<Errors, AbstractResponse> responseFactory,
+        Function<Admin, KafkaFuture<Void>> adminCall,
+        List<Errors> responsesToPrepare,
+        Class<? extends Throwable> expectedException
+    ) throws ExecutionException, InterruptedException {


this added abstraction feels a bit heavy - I see that there are similarities between unregister_broker and unregister_controller but imo this makes figuring out what the tests are doing a little too opaque

Basically, I just copied the unregister broker tests, but that resulted in lots of duplicate code.

ahuang98 · 2026-05-22T05:33:27Z

+        UnregisterControllerRequest request = new UnregisterControllerRequest.Builder(
+            new UnregisterControllerRequestData()
+        ).build((short) 0);
+        String customerErrorMessage = "customer error message";


customer feels like an odd choice here? did you mean custom?

This was copied from the broker test above it haha. I can change both.

ahuang98 · 2026-05-22T06:19:00Z


+    @Override
+    public UnregisterControllerResult unregisterController(int controllerId, UnregisterControllerOptions options) {
+        if (usingRaftController) {


interesting, seems like we have more dead code to remove

ahuang98 · 2026-05-22T06:36:01Z

+    registrationModifier: RegisterControllerRecord => Option[RegisterControllerRecord],
+    unregisterModifier: UnregisterControllerRecord => Option[UnregisterControllerRecord]


I know you're just extending the same semantics, but man these are so hard to reason about - can we add comments/examples?

I agree the modifier pattern can be a bit confusing, but I think this is outside of the scope of this PR. This file will get converted to java at some point, and maybe after that we can clean this up. What do you think?

ahuang98 · 2026-05-22T07:06:14Z

+  }
+
+  @Test
+  def testReRegistrationAfterDifferentIncarnationId(): Unit = {


just confirming, is this new or existing behavior that we're just adding test coverage for?

This is existing behavior. From ControllerRegistrationManager:

} else if (!curRegistration.incarnationId().equals(incarnationId)) { logger.info("Found registration for {} instead of our incarnation.", curRegistration.incarnationId()); registeredInLog = false;

setting the registeredInLog = false tells the manage to send ControllerRegistrationRequest.

ahuang98 · 2026-05-22T07:20:17Z

                .action(store())
                .required(true)
                .help("The ID of the broker to unregister.");
+        unregisterControllerParser.addArgument("--controller-id", "-i")


thoughts on just using "--id" here given that the subcommand is pretty self-explanatory ("unregister-controller")?

ahuang98 · 2026-05-22T07:21:45Z

+        } catch (ExecutionException ee) {
+            Throwable cause = ee.getCause();
+            if (cause instanceof UnsupportedVersionException) {
+                stream.println("The target cluster does not support the controller unregistration API.");


is the original exception message not descriptive enough?

This is also copied from the broker unregistration case.

Instead of dumping a stack trace in the case the cluster does not support the MV for unregistering controllers, it prints a simple message to the user. I think that is better UX for this case. I think we should also handle this in a similar way for other "expected exceptions" like InvalidRequestException, and ControllerIdNotRegisteredException. What do you think?

my comment applies to the broker unregistration case too, the original exception messages feel sufficient (and are more actionable in that they specifically mention MV is insufficient) so it feels odd we don't just include that in the output here. in any case, we don't have to change existing behavior in this PR and we can just have the controller unregistration API match

ahuang98 · 2026-05-22T07:24:26Z

+                    + ". To unregister the controller from the cluster, run "
+                    + "`kafka-cluster.sh unregister-controller --controller-id "
+                    + controllerId + "`.");


hm, should we include the original exception so the client knows why removeRaftVoter failed?

also, if the removal fails due to UnsupportedVersionException then wouldn't unregisterController also be unsupported?

hm, should we include the original exception so the client knows why removeRaftVoter failed?

Throwing TerseException strips the stack trace, but that only occurs when the user tries to remove AND unregister the controller in the same command. In any case, we still print cause.getMessage(), so we'll see Kafka's message when initializing the exception IIUC.

For these two exceptions specifically, I wanted to have the ability to direct the user to run the other tool if they want to unregister the controller, since removing the voter is not possible if those exceptions are returned.

also, if the removal fails due to UnsupportedVersionException then wouldn't unregisterController also be unsupported?

UnsupportedVersionException being returned by RemoveRaftVoterRequest means the cluster is kraft.version=0. You could still unregister a controller in a static quorum cluster, since kraft.version is a different feature from MV. For example, you can have an observer that does not set controller.quorum.voters and instead sets controller.quorum.bootstrap.servers.

I missed ": " + cause.getMessage()

nice, forgot those are gated by different features

ahuang98 · 2026-05-22T07:29:28Z

+            throw new TerseException("Removed KRaft voter " + controllerId
+                + " but failed to unregister it: "


this doesn't seem like the right place to log a successful kraft voter removal

I see. In handleRemoveController we print out something if removeRaftVoter returns successfully.

ahuang98 · 2026-05-22T07:31:12Z

+        assertTrue(outputs.contains("DRY RUN of removing  KRaft controller 2 with directory id _KWDkTahTVaiVVVTaugNew"),
+            "Failed to find expected output in stdout: " + outputs);
+        assertTrue(outputs.contains("DRY RUN of unregistering  KRaft controller 2"),


nit, looks like we are printing extra whitespace

junrao

@kevin-wu24 : Thanks for the PR. Made a pass of non-testing files. Just a few minor comments.

junrao · 2026-07-22T17:36:31Z

 $ bin/kafka-metadata-quorum.sh --bootstrap-controller localhost:9093 remove-controller --controller-id <id> --controller-directory-id <directory-id>
 ```

+To also unregister the controller from the cluster metadata after it has been removed from the voter set, pass the `--unregister` flag: 


This is a bit confusing. It reads as if one can call kafka-metadata-quorum.sh first to remove the node from the voter set and then call it again to unregister it.

The idea was to provide one CLI invocation for operators to allow for the "voter removal + unregistration" to happen in one CLI command. I can reword this comment to make it more clear.

junrao · 2026-07-22T17:40:22Z

+ * Options for {@link Admin#unregisterController(int, UnregisterControllerOptions)}.
+ */
+@InterfaceAudience.Public
+public class UnregisterControllerOptions extends AbstractOptions<UnregisterControllerOptions> {


This is not defined in the KIP. Could you add it there?

junrao · 2026-07-22T17:45:56Z

+     *   <li>{@link org.apache.kafka.common.errors.TimeoutException}
+     *   If the request timed out before the unregister operation could finish.</li>
+     *   <li>{@link org.apache.kafka.common.errors.UnsupportedVersionException}
+     *   If the software is too old to support the unregistration API.


The KIP also includes NOT_CONTROLLER and INVALID_REQUEST.

junrao · 2026-07-22T20:45:41Z

                .action(store())
                .required(true)
                .help("The ID of the broker to unregister.");
+        unregisterControllerParser.addArgument("--id", "-i")


The KIP uses --controller-id. Should we update the KIP?

junrao · 2026-07-22T20:52:49Z

+            throw new TerseException("Failed to unregister controller " + controllerId
+                + ": " + (cause != null ? cause.getMessage() : e.getMessage())
+                + ". To unregister the controller from the cluster, run "
+                + "`kafka-cluster.sh unregister-controller --id "


Hmm, if the unregister fails here, will it ever be successful using kafka-cluster.sh unregister-controller?

I'd argue yes. Many things could cause this second RPC loop to fail after the first succeeds. Some examples include: network partitions, leadership changes, and a cluster MV that does not support unregistering.

My goal for this exception handling is to direct the user to the kafka-cluster unregister-controller command, which only handles unregistering controllers. The kafka-metadata-quorum remove-controller --unregister can do two things. Attempting to unregister is conditioned on voter removal succeeding.

junrao · 2026-07-22T22:43:33Z

+    ) {
+        return appendWriteEvent("unregisterController", context.deadlineNs(),
+            () -> {
+                if (nodeId == controllerId && isActiveController()) {


isActiveController() seems redundant since this code runs under ControllerWriteEvent.run() that checks activeController already.

junrao · 2026-07-22T22:49:01Z

+        } catch (ExecutionException e) {
+            Throwable cause = e.getCause();
+            throw new TerseException("Failed to unregister controller " + controllerId
+                + ": " + (cause != null ? cause.getMessage() : e.getMessage())


We check for null here, but not in line 535. Could we be consistent?

For L535, because we are checking:

(cause instanceof UnsupportedVersionException || cause instanceof VoterNotFoundException))

cause != null is always true.

I wonder if we should make this command's behavior idempotent though in the case of VoterNotFoundException. Meaning that, if the voter is already gone from the voter set, we should try to unregister it, rather than throwing an exception. There is a precedent for this in other CLIs like kafka-storage format --ignore-formatted. What do you think?

Hmm, not sure about treating VoterNotFoundException the same as the voter is gone. removeRaftVoter takes both controllerId and directoryId. VoterNotFoundException could also mean the voter is still there, but the directoryId is incorrect.

VoterNotFoundException could also mean the voter is still there, but the directoryId is incorrect.

Hmm, yeah. I don't think there is a way to differentiate between those two cases. I think I'll just leave the behavior as is.

junrao · 2026-07-22T22:55:59Z


+    public void replay(UnregisterControllerRecord record) {
+        int controllerId = record.controllerId();
+        ControllerRegistration registration = controllerRegistrations.get(controllerId);


We can just call remove() here since it returns the previous value if present.

junrao

@kevin-wu24 : Thanks for the updated PR. Looks good to me overall. Just a minor comment.

junrao · 2026-07-24T00:19:26Z

+        } catch (ExecutionException e) {
+            Throwable cause = e.getCause();
+            throw new TerseException("Failed to unregister controller " + controllerId
+                + ": " + (cause != null ? cause.getMessage() : e.getMessage())


Hmm, not sure about treating VoterNotFoundException the same as the voter is gone. removeRaftVoter takes both controllerId and directoryId. VoterNotFoundException could also mean the voter is still there, but the directoryId is incorrect.

ChetanKoneru · 2026-07-29T13:12:32Z

Thank you for working on this—this is directly relevant to a production stale-controller recovery case we have.

see - https://github.com/orgs/strimzi/discussions/13001

We run a Strimzi Kafka with KRaft on AKS. After upgrading Strimzi 0.42.0 -> 0.45.2 and Kafka 3.7.1 -> 3.9.2, the cluster is healthy (Ready=True) but cannot finalize the metadata upgrade from 3.7-IV4 to 3.9-IV0.

Strimzi: 0.45.2
Kafka: 3.9.2
KRaft metadata state: KRaft
Finalized metadata: 3.7-IV4
Requested metadata: 3.9-IV0

Active brokers: 0,1,2
Active controllers: 90,91,92
status.registeredNodeIds: [0,1,2,90,91,92]

During the original ZooKeeper-to-KRaft migration, the controller NodePool did not have reserved node IDs, so controllers were assigned 3,4,5. We later reserved IDs explicitly:

broker NodePool
strimzi.io/next-node-ids: "[0-49]"

controller NodePool
strimzi.io/next-node-ids: "[90-99]"

The active controller NodePool now uses 90,91,92. Controllers 3,4,5 are no longer Pods or quorum voters, but their registrations remain in __cluster_metadata:

ControllerRegistration(id=3, supportedFeatures={metadata.version: 1-19})
ControllerRegistration(id=4, supportedFeatures={metadata.version: 1-19})
ControllerRegistration(id=5, supportedFeatures={metadata.version: 1-19})

The active controllers and brokers support metadata feature levels 1-21. The metadata upgrade fails because the stale registration still participates in validation:

InvalidUpdateVersionException:
Invalid update version 21 for feature metadata.version.
Controller 5 only supports versions 1-19

As the safe mitigation, we retain Kafka 3.9.2 but keep the desired metadata version at 3.7-IV4. This stops repeated failed update attempts, but leaves the expected incomplete-upgrade warning.

We understand this PR adds Admin#unregisterController, kafka-cluster.sh unregister-controller, and UnregisterControllerRecord, which is exactly the missing capability.

Could you clarify whether this operation requires the cluster to have already finalized the metadata version that supports UnregisterControllerRecord (currently proposed as IBP_4_4_IV1)?

If so, this existing-cluster recovery case appears circular:

Stale controller registrations must be removed to advance metadata.
The proposed controller-unregistration record requires newer metadata.
Advancing metadata is blocked by those same stale registrations.

Is an in-place repair path for clusters stuck at an older finalized metadata version in scope for this PR or planned separately? In particular, is there a supported way to unregister obsolete controller registrations while retaining metadata.version=3.7-IV4?

kevin-wu24 · 2026-07-29T14:55:58Z

Hi @ChetanKoneru,

Thanks for the questions. Please see the compatibility section and rejected alternatives sections of KIP-1312: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=406623954#KIP1312:Supportunregisteringcontrollers-Compatibility,Deprecation,andMigrationPlan. This feature only applies to new clusters going forward. In many cases, operators can "refresh" a stale controller registration by bringing up a controller with the same node id as the stale registration. I'm not familiar with Strimzi's operator, so I cannot speak to your specific case unfortunately.

Could you clarify whether this operation requires the cluster to have already finalized the metadata version that supports UnregisterControllerRecord (currently proposed as IBP_4_4_IV1)?

Yes, clusters need a metadata version that supports the record to serialize and deserialize it. New metadata records must be gated behind new metadata versions. This is because a given metadata version must be supported by all nodes registered with the cluster to be finalized.

Is an in-place repair path for clusters stuck at an older finalized metadata version in scope for this PR or planned separately?

This is not in scope for this PR or planned separately.

junrao

@kevin-wu24 : Thanks for the updated PR. A few more comments.

junrao · 2026-07-29T21:18:19Z

+                if (nodeId == controllerId) {
+                    throw new InvalidRequestException("Controller cannot unregister itself while it is active.");
+                }
+                return clusterControl.unregisterController(controllerId);


Finding from Claude.

Should we remove the controllerId from FeatureControlManager's quorumFeatures.quorumNodeIds()? Otherwise, this unregistered controller can block future MV upgrades.

Should we remove the controllerId from FeatureControlManager's quorumFeatures.quorumNodeIds()?

I'm looking at FeatureControlManager#reasonNotSupported, which is how we validate the cluster members support a feature upgrade via their registrations. It looks like we do look through the broker + controller registrations, which is good.

From my reading, the quorumNodeIds check on FeatureControlManager L360 serves as a way to check that the static voter set members from controller.quorum.voters are all registered with the cluster prior to an upgrade. If the config is not set, then this field is an empty list.

From https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=406623954#KIP1312:Supportunregisteringcontrollers-UserExperience, and assuming the voter in question is not able to send a registration, we should not be unregistering a member of the static voter set without removing it from that config first. The UX guide recommends removing the controller from the voter set config prior to unregistering it. This means the lack of a registration from a static voter SHOULD block feature upgrades in my opinion. Therefore, I think the quorumNodeIds check is correct here. What do you think?

Actually, one check we can add is rejecting the unregister request if the controller id appears in quorumFeatures.quorumNodeIds(), since that means the id is part of controller.quorum.voters. This will help ensure users remove the controller id from the static voter set before unregistering it.

The KIP says the following.

Unregister a voter in a static KRaft quorum when the static voter set is mistakenly configured 1. Stop the voter who was mistakenly put in controller.quorum.voters 2. Run kafka-cluster unregister-controller 3. Ensure the stopped voter is not part of controller.quorum.voters on every Kafka node

What will be the new sequence?

Run kafka-cluster unregister-controller would be step 3. Stopping the voter and removing it from all controller.quorum.voters configs can be done interchangeably I believe.

That is to say, the preconditions for unregistering a controller with id X in a static quorum are:

X is not present in controller.quorum.voters

X is not running (if it is it will re-register)

Ideally, we should have the same pre-requisites for dynamic quorum WRT the voters set. I think the approach would be analogous to using RaftControllerNodeProvider or KRaftVersionAccessor to extract raft internal state. Maybe it is okay to file a JIRA for this as a follow-up instead, since unregistering a live voter in either quorum mode will cause the voter to register itself again, so the cluster can recover from that "incorrect" operation. What do you think @junrao?

Thanks. Sounds good. Could you update the PR and the KIP?

Filed https://issues.apache.org/jira/browse/KAFKA-20865.

junrao · 2026-07-29T21:24:35Z

+        int controllerId = record.controllerId();
+        ControllerRegistration registration = controllerRegistrations.remove(controllerId);
+        if (registration == null) {
+            throw new RuntimeException(String.format("Unable to replay %s: no controller " +


Finding from Claude.

UnregisterBrokerRecord has a brokerEpoch field, which is checked during replay. UnregisterControllerRecord doesn't have a brokerEpoch field. Why the inconsistency?

UnregisterControllerRecord doesn't have a brokerEpoch field. Why the inconsistency?

The main reasons are that brokerEpoch is used for broker lifecycle management between broker and active controller, such as fencing, unfencing, and clean shutdown detection.brokerEpoch also provides the active controller with a mechanism for detecting a request from a "zombie-broker" incarnation/registration and reject it.

However, controller registration is more "simple" IMO, in that they only really are needed by the metadata layer to know each controller's endpoints + supported features. These are properties which only change on a process restart, and controllers will refresh their registrations on restart because they will not see their incarnation ID in the existing registration.

junrao · 2026-07-29T21:56:40Z

+      // initial state with controller registered in log
+      val image = doMetadataUpdate(MetadataImage.EMPTY,
+        manager,
+        MetadataVersion.IBP_3_7_IV0,


Why do we use an old MV? Ditto below.

Thanks for catching this. Adding a MV check. The test below doesn't test unregistering, just re-registering when the existing registration has the wrong incarnation ID, so I will leave it as is, since that old MV supports registration.

junrao · 2026-07-29T21:59:07Z

+            int controllerIdToUnregister = cluster.controllers().keySet().iterator().next();
+            cluster.controllers().get(controllerIdToUnregister).shutdown();
+
+            try (Admin admin = createAdminClient(cluster, usingBootstrapControllers)) {


Do we guarantee that the active controller is elected when we get here?

Added a cluster.waitForActiveController call in both tests.

junrao · 2026-07-29T22:02:24Z

+
+    @Override
+    public boolean shouldClientThrottle(short version) {
+        return true;


We don't need to override the method now that we merged #22908

junrao · 2026-07-29T22:05:08Z

+  "validVersions": "0",
+  "flexibleVersions": "0+",
+  "fields": [
+    { "name": "ControllerId", "type": "int32", "versions": "0+",


Should we add "entityType" following UnregisterBrokerRequest?

I'm not super clear on the purpose of entityType, but I did not add it because RegisterControllerRecord does not use it either. This is what claude said:

entityType is nearly inert in codegen. The only consumers are FieldSpec.java:100, which calls verifyTypeMatches to assert the declared type matches the entity's base type (brokerId → int32), and Target.java:50, which just copies it through.

junrao · 2026-07-29T22:09:08Z

+     * returned {@link UnregisterControllerResult}:
+     * <ul>
+     *   <li>{@link org.apache.kafka.common.errors.TimeoutException}
+     *   If the request timed out before the unregister operation could finish.</li>


Should we add </li> for the remaining <li>?

ppatierno · 2026-07-30T10:47:42Z

This feature only applies to new clusters going forward. In many cases, operators can "refresh" a stale controller registration by bringing up a controller with the same node id as the stale registration. I'm not familiar with Strimzi's operator, so I cannot speak to your specific case unfortunately.

@kevin-wu24 sorry if I missed that in the rejected alternatives during KIP discussion but let me ask a question. If the Kafka cluster is running by using static quorum, the KIP suggest to "refresh" the node ID by scaling up a new controller with same ID and then scale it down again. Doesn't it go against the way the static quorum works and cannot be changed? (so dynamic quorum was developed).

kevin-wu24 · 2026-07-30T12:40:13Z

This feature only applies to new clusters going forward. In many cases, operators can "refresh" a stale controller registration by bringing up a controller with the same node id as the stale registration. I'm not familiar with Strimzi's operator, so I cannot speak to your specific case unfortunately.

@kevin-wu24 sorry if I missed that in the rejected alternatives during KIP discussion but let me ask a question. If the Kafka cluster is running by using static quorum, the KIP suggest to "refresh" the node ID by scaling up a new controller with same ID and then scale it down again. Doesn't it go against the way the static quorum works and cannot be changed? (so dynamic quorum was developed).

@ppatierno not necessarily. Having observer controllers is still a valid cluster configuration in static quorum. For example, you can bring a up a node in a static quorum cluster whose configuration uses controller.quorum.bootstrap.servers to discover the quorum, rather than controller.quorum.voters. Stale controller registrations only apply to observers, because otherwise, your cluster has a voter set failure/misconfiguration. The difference is that in a static quorum, you cannot promote the observer controller to a voter, which you can do in dynamic quorum.

junrao

@kevin-wu24 : Thanks for the updated PR. Just a couple of minor comments.

junrao · 2026-07-30T17:22:53Z

      }
    }
+    if (metadataVersion.isControllerUnregistrationSupported) {
+     for (i <- Seq(1, 2, 3)) {


Fixed in 61446f5

junrao · 2026-07-30T17:41:10Z

+                if (nodeId == controllerId) {
+                    throw new InvalidRequestException("Controller cannot unregister itself while it is active.");
+                }
+                return clusterControl.unregisterController(controllerId);


The KIP says the following.

Unregister a voter in a static KRaft quorum when the static voter set is mistakenly configured 1. Stop the voter who was mistakenly put in controller.quorum.voters 2. Run kafka-cluster unregister-controller 3. Ensure the stopped voter is not part of controller.quorum.voters on every Kafka node

What will be the new sequence?

junrao

@kevin-wu24 : Thanks for the updated PR. LGTM Do you know why the CI failed?

kevin-wu24 · 2026-07-31T14:42:35Z

Thanks for the reviews @junrao.

Do you know why the CI failed?

Not sure. It seems unrelated. I think the Java 17 unit test step timed out with 2 flaky tests? This is what I see:

Gradle task had a timeout. Failing this script. These are partial results!

Are you able to re-run that task? I don't think I can.

junrao · 2026-07-31T18:20:19Z

I triggered a rerun of all jobs. You can also rebase to trigger a rerun yourself.

junrao · 2026-07-31T18:31:08Z

Hmm, my rerun also failed. Could you rebase to trigger another rerun?

kevin-wu24 · 2026-08-03T14:25:58Z

Could you rebase to trigger another rerun?

Sure. It looks like the re-run passed.

kevin-wu24 added 4 commits April 6, 2026 09:24

add RPC and record schemas for unregistering controllers

55e5808

use BrokerUnregisterRecord for unregistering controllers

7ccf5a8

revert back to UnregisterControllerRecord approach

6a47cf7

cleanup

bc00c2c

github-actions Bot added triage PRs from the community streams core Kafka Broker tools kraft clients labels May 1, 2026

kevin-wu24 added 2 commits May 1, 2026 11:02

merging trunk

9832615

cleaned up tests, fixed MV after merging trunk, and updated kafka-met…

c97da54

…adata-quorum tool error handling

github-actions Bot added the needs-attention label May 9, 2026

kevin-wu24 added 2 commits May 12, 2026 15:00

add exception for controller not registered and integration test

7006e04

Merge branch 'trunk' into KAFKA-20395

22d2836

github-actions Bot removed the needs-attention label May 13, 2026

github-actions Bot added the needs-attention label May 14, 2026

leader should not unregister itself

3bba8cb

github-actions Bot removed the needs-attention label May 15, 2026

github-actions Bot added the needs-attention label May 16, 2026

kevin-wu24 added 2 commits May 18, 2026 09:37

merging trunk

4a003a4

cleanup

8695b89

kevin-wu24 marked this pull request as ready for review May 18, 2026 15:03

github-actions Bot removed the needs-attention label May 19, 2026

github-actions Bot added the needs-attention label May 20, 2026

ahuang98 reviewed May 22, 2026

View reviewed changes

Kevin Wu added 3 commits July 16, 2026 10:57

merging trunk

fb0a3ca

cleanup + add docs

caf978e

add interface annotation

d227f07

junrao reviewed Jul 22, 2026

View reviewed changes

code review

0e1303f

junrao reviewed Jul 24, 2026

View reviewed changes

merging trunk

ec8a716

merging trunk

4259c72

junrao reviewed Jul 29, 2026

View reviewed changes

Kevin Wu added 3 commits July 30, 2026 10:29

code review

f5dc5fe

code review

61446f5

merging trunk

65aa8b1

junrao reviewed Jul 30, 2026

View reviewed changes

Kevin Wu and others added 3 commits July 30, 2026 13:04

fix test

567d2b5

revert static voter set check

d17872e

cleanup

5041ff9

junrao approved these changes Jul 31, 2026

View reviewed changes

davide-armand mentioned this pull request Jul 31, 2026

KAFKA-20295: Add opt-in workaround for stale controller registrations during metadata.version upgrades aiven/kafka#69

Open

Retrigger CI

4bde1e7

HelenMel mentioned this pull request Aug 3, 2026

[KAFKA-20295] decommision (pre-unregister) controller patch aiven/kafka#70

Open

davide-armand mentioned this pull request Aug 3, 2026

KAFKA-20295: Use current quorum voters for feature validation #23038

Open

junrao merged commit c274a73 into apache:trunk Aug 3, 2026
20 checks passed

		registrationModifier: RegisterControllerRecord => Option[RegisterControllerRecord],
		unregisterModifier: UnregisterControllerRecord => Option[UnregisterControllerRecord]

		throw new TerseException("Removed KRaft voter " + controllerId
		+ " but failed to unregister it: "

Uh oh!

Conversation

kevin-wu24 commented May 1, 2026 • edited by github-actions Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What Changed

Testing

Uh oh!

github-actions Bot commented May 9, 2026

Uh oh!

github-actions Bot commented May 14, 2026

Uh oh!

github-actions Bot commented May 16, 2026

Uh oh!

github-actions Bot commented May 20, 2026

Uh oh!

ahuang98 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kevin-wu24 May 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

junrao left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

kevin-wu24 commented May 1, 2026 •

edited by github-actions Bot

Loading

kevin-wu24 May 22, 2026 •

edited

Loading

kevin-wu24 Jul 23, 2026 •

edited

Loading

kevin-wu24 Jul 24, 2026 •

edited

Loading