fix(database): five HA defects an adversarial audit of #1143 confirmed live

[paulocsanz]

Follow-up to #1143, which is merged and released as v5.46.0. An adversarial audit of that PR's content found five defects that are live in the released CLI. Each is independently reachable; they are grouped here because they were found in one pass over the same feature.

Redis/MySQL scale restamps consensus quorum on the whole fleet

restamp_replica_wiring wrote quorumVariable to the root and every replica, while the peer-list block directly above it stamped joining nodes only and carried a comment explaining why.

A running node reads that env exactly once, on the first boot that writes its coordinator config, and never again — so the edit changed nothing functionally, while still marking every node stale. That is a simultaneous fleet-wide restart, racing the coordinator into a spurious failover mid-scale. And on a real cluster the survivors' copy is a reference to the root's (${{Redis-1.SENTINEL_QUORUM}}), so overwriting it with a literal was not even a no-op edit — it detached them from the root's value.

Now stamped on joining nodes only, matching useScaleHACluster.tsx. A scale-down stamps nothing at all: survivors converge through the image's own quorum-sync watcher as removed nodes drop out. The per-replica identity variable moves to joining-nodes-only for the same reason — a replica's identity is its own name, which a scale never changes.

The routing edge's data-node list stays fleet-wide. It is read per connection, not once at boot.

ha revert's debris sweep was environment-wide and engine-blind

The sweep deleted any parentless, role-stamped service in the environment. In a mixed environment, reverting a Redis cluster deleted the Postgres cluster's live-scaled replicas — a clusterRole stamp was the only thing standing between an unrelated service and deletion.

The orphan scan is now scoped to services running an image the engine's own companion publishes, read off the companion record. Each companion publishes under its own prefix (postgres-ha/*, redis-ha/*, mysql-ha/*), which is the surviving evidence of which companion built a service once the parent link is gone — read from the record, so a template that adds a sidecar the CLI has never heard of stays covered.

An unreadable record skips the debris scan and warns, rather than widening it to everything: the snapshot members are the part that is still provable. The resume path also now names the services it is about to delete instead of only counting them — it deletes services the user never listed, on evidence they cannot see.

The pooler exclusion is unchanged and still needed on the snapshot path, where the pooler is a genuine child of the root.

CLI-scaled replica volumes bypassed primary-size matching

The volume instance was provisioned by volumeCreate directly, ahead of the patch that stamps the node's clusterRole/parentServiceId — the exact pair backboard's resolveNewVolumeInstanceSizeMB keys on to size a replica volume to hold a full base backup of its primary. Created before either existed, it read as an ordinary volume and landed on the flat plan default, reintroducing the undersized-replica-volume class for CLI scaling.

The record is now created bare (environmentId: null) and the instance is staged in the same patch as the role and parent — the split useScaleHACluster already uses. It also drops a patch-system redeploy per volume.

Tag parsing diverged from the server, producing false refusals

The CLI required a tag component to be numeric end to end; the server's extractImageTagVersion reads the leading major[.minor] and ignores everything past it.

tag	server	CLI (before)
redis:8.2-alpine	8.2	major 8, no minor
redis:7-bookworm	major 7	no version at all

Both were refused by a CLI pre-flight for conversions the server would have accepted. Now mirrors the server. The test that codified the old parse is corrected rather than kept.

--service pointed at a replica stood in for the root

resolve_root_service_id hopped only edge to its parent, so a replica resolved to itself. ha revert then prechecked the replica's primariness, handed templateRevert the replica's id (whose resolver does no root validation), and took a sweep snapshot in which the true root was just another deletable member. Every member role now hops. Preexisting, and inherited by all three engines when the tree was generalized.

Not fixed here

The mono-side root cause that feeds the orphan population above: the patch path drops parentServiceId. packages/backboard/src/temporal/workflows/environments/activities/service.ts applies clusterRole for an existing instance on its update branch but has no equivalent block for the parent link, and serviceCreate(environmentId) pre-creates the instance so the create branch (which does set it) never runs for live scale-ups. CLI and dashboard are both affected; the dashboard compensates through canvas groups, which the public API cannot stamp. Separate repo, separate PR.

Verification

• cargo test — 1310 pass. New coverage: joining-nodes-only restamp on scale-up and the no-op scale-down, a Redis revert leaving a Postgres cluster untouched, the unreadable-companion degrade, every member role resolving to its root, the companion-repository reader (exact match, not prefix), and an end-to-end scale against a stub backboard asserting the volume is staged rather than pre-provisioned and that survivors go unstamped.
• Each fix was re-reverted individually to confirm its own test fails without it — none of these pass against the old behavior.
• cargo clippy --all-targets and cargo fmt --check clean; no new warnings in any touched file.
• The three companion records (postgres-ha, redis-ha, mysql-ha) were read from the live API to confirm the per-companion repository prefixes the sweep scope relies on, rather than assumed.