StarRocks logical restore lacks trustworthy target topology and expected service version

[weicao]

Problem observed

This issue was found in one StarRocks Enterprise logical backup/restore BR-R7 case.

The observed sequence was:

1. the source logical backup completed;
2. the target FE/BE restore PVCs became Bound;
3. the later postReady restore Job stopped before database-changing commands because the addon had source metadata but no trustworthy target topology or target service-version input.

The addon checks topology and version compatibility before ensure_repository and RESTORE SNAPSHOT. Runtime evidence is one missing-input case; runtime validation of the controller fix remains N=0.

Correctness requirements

A caller-supplied environment string cannot prove the target. Values used by a new postReady Job must be derived from trusted Kubernetes objects at Job dispatch, after the exact target Pod is selected.

The dispatch contract must:

• re-read the selected Pod and verify its UID, readiness, and workload ownership;
• use Instance.spec.instanceTemplateName for an Instance-owned Pod instead of a mutable Pod label;
• reject a terminating Instance or InstanceSet before consuming its spec, label, or parent ownership state;
• verify that the workload belongs to the target Component;
• require the current Component generation to be observed and Running;
• verify Component identity labels and its controller-written Cluster UID annotation;
• read topology from the matching current Cluster;
• prevent Restore, ActionSet, BackupMethod, credential, or Pod environment values from overriding reserved target inputs;
• preserve an already-created Job as the durable action record.

Version semantics

The Apps API defines serviceVersion as the Component expected service version. It does not define selector/range syntax and does not claim that the field is the actual runtime database version.

The transitional protocol therefore preserves the owning API semantics for the exact selected Pod:

• DP_TARGET_CLUSTER_TOPOLOGY: current Cluster.spec.topology;
• DP_TARGET_COMPONENT_SERVICE_VERSION: an active instance-template override when declared, otherwise Component.spec.serviceVersion.

An empty expected version means Apps exposes no expected serviceVersion; it makes no claim about the concrete version currently running. The addon must decide whether that input is sufficient for its compatibility policy.

Selected design in #10678

1. Internal postReady Restores do not carry an authoritative target snapshot.
2. BuildPostReadyActionJobs resolves and verifies target metadata through the uncached API reader immediately before each new Job is built.
3. Reserved target names from ordinary environment sources are stripped. The experimental DP_TARGET_COMPONENT_SERVICE_VERSION_SELECTOR name is strip-only and is never emitted.
4. Verified topology and expected service version are appended once to the final Job environment.
5. Existing in-flight and terminal Jobs are not rebuilt from later target state.
6. Missing or not-yet-observed target state requeues; identity changes and authorization failures fail closed.

Rejected alternatives

• trusting mutable Restore.spec.env as its own authority;
• freezing a creation-time snapshot that can be stale at later Job dispatch;
• using a Pod implementation label after the authoritative Instance API has been read;
• inventing selector syntax for Apps expected serviceVersion;
• describing Apps desired state as a runtime-discovered version;
• adding a broad public facts API without completing the consumer and authority design tracked in Make controller-owned DataProtection addon inputs API-discoverable #10682.

Validation boundary

Source/unit/envtest validation covers Restore mutation, dispatch-time Component changes, Instance API source-of-truth conflicts, direct InstanceSet compatibility, empty expected versions, stale observed generation, identity/ownership checks, reserved-name conflict removal, and preservation of existing Jobs.

A fresh exact-image StarRocks restore is still required before making a runtime-pass or release-readiness claim.

[github-actions]

This issue has been marked as stale because it has been open for 30 days with no activity

[leon-ape]

I have taken this issue over. The smaller replacement implementation is in #10838: resolve topology and expected serviceVersion after selecting the target Pod, then override the two Job environment values at the final rendering boundary.