[BUG] kbcli 1.0.2 cannot decode KubeBlocks 1.2 Cluster after reconfigure

[shanshanying]

Describe the bug

When kbcli v1.0.2 is used against KubeBlocks 1.2, a reconfiguration can make unrelated cluster commands fail with:

error: cannot restore struct from: bool

Known affected commands include:

kbcli cluster list-instances <cluster>
kbcli cluster delete <cluster> --auto-approve

The commands fail while decoding the Cluster object, before performing their intended operation.

To reproduce

1. Install KubeBlocks 1.2.0-alpha.2 and kbcli 1.0.2.
2. Create a Cluster and wait for it to become Running.
3. Run a Reconfiguring OpsRequest.
4. Confirm the Cluster contains configuration intent similar to:

spec:
  componentSpecs:
  - configs:
    - name: mysql-replication-config
      configHash: 7756c849f4
      reconfigure: true
      restart: false

5. Run either affected command.

Root cause

This is a version-locked typed-decoding failure.

• kbcli v1.0.2 pins KubeBlocks v1.0.1.
• In the older KubeBlocks model, ClusterComponentConfig.reconfigure is *Action.
• In the current model, the same apps.kubeblocks.io/v1 JSON field is *bool, with the action moved to reconfigureAction.
• kbcli v1.0.2 converts the complete unstructured Cluster into its compiled KubeBlocks type using runtime.DefaultUnstructuredConverter. The delete path does this in getClusterFromObject, and the cluster object getter used by list commands does the same.

The converter therefore tries to restore the live boolean value into the old Action struct and returns cannot restore struct from: bool. The whole command fails even though list-instances and normal deletion do not need the reconfigure payload.

Simply updating the KubeBlocks Go dependency fixes only one direction. If kbcli is expected to work across KubeBlocks versions, decoding must tolerate both the historical Action-shaped value and the current boolean-shaped value.

Why server-side cleanup is not a complete fix

KubeBlocks PR #10496 attempted to clear the transient fields after all replicas reached the target config hash. That only shortens the failure window after successful convergence. It does not help while an operation is active, failed, or paused, and it couples KubeBlocks controller state semantics to one older client decoder. The PR was closed in favor of tracking the compatibility problem here.

The reuse of one v1 JSON field with a different type is also an API-evolution concern in KubeBlocks, but kbcli should not fail an unrelated command merely because an unused field has a newer representation.

Proposed solution

Introduce a tolerant compatibility seam for Cluster reads used by commands, for example:

• Decode only the fields each command needs through a kbcli-owned projection or unstructured access, instead of converting the entire Cluster into a version-specific KubeBlocks struct; or
• Add version-aware decoding that accepts both reconfigure: <Action> and reconfigure: <bool> and normalizes them internally.

Also return a clear version-compatibility error when a required field truly cannot be interpreted. Avoid relying only on a KubeBlocks dependency bump if cross-version operation is expected.

Acceptance criteria

• cluster list-instances and cluster delete do not fail when the Cluster contains either the historical Action-shaped or current boolean-shaped reconfigure value.
• Add regression fixtures for both schema shapes to the list and delete paths.
• Fields unrelated to a command do not prevent that command from running.
• If a combination is intentionally unsupported, kbcli reports the supported compatibility range instead of a raw converter error.

Related KubeBlocks report: apecloud/kubeblocks#10370.