Page History

...

When the active controller receives the updateFeatures RPC, it will check whether all the controllers and brokers in the cluster support the new metadata version described above. If any of them do not support the new metadata version, we return INVALID_UPDATE_VERSION, with an error message identifying the server that doesn't support downgrade. It will also check that the requested metadata version is compatible with all the other KIP-584 features that are enabled.

If the metadata version is too old to support KIP-919 controller registrations (pre 3.7.0-IV0), we will simply assume that the controllers do support downgrade, because we cannot check. This is similar to how metadata version upgrade is handled in the absence of controller registrations.

Downgrading to a metadata.version level older than 3.3-IV3 7 will not be supported. The rationale reason for this is described in that that is the first version that supported  KIP-896, which removed support for metadata versions older than 3.3-IV3919 controller registrations, and we rely on the controller registrations to check that a proposed new MV or other feature is supported by all controllers. Since this is a fairly old MV at this point, this shouldn't be a significant restriction.

If all of these checks succeed, the active controller will handle the downgrade operation by emitting a FeatureLevelRecord for metadata.version with the new feature level. If the updateFeatures RPC specified multiple features, the metadata version downgrade record will be emitted last.

...