Problem
Scaling a Redis Cluster from 3 to 4 shards completes the object-level topology quickly, but slot migration duration depends on data volume, network, and disk — it cannot be bounded by the synchronous lifecycle action's 60s clamp.
Observed field case (Redis 5.0.12, chart redis-1.2.0-alpha.5): topology reached 8 nodes / 4 masters / 16384 slots within 28s after scale-out, but 29 consecutive checks over 420s never closed and the Cluster stayed Updating. The original migration command logs had rotated, so the evidence proves the synchronous shardAdd action failed to reliably close the long migration; it does not prove a specific timeout root cause (runtime N=1, scoped observation).
The public contract today only promises a synchronous shardAdd action; there is no managed long-task contract. The inline action has no persistent execution identity, no recoverable Job, and no terminal evidence — controller restarts, lost status confirmations, object replacement, or definition drift can strand the scale-out or risk blind replay of a global, non-idempotent migration.
Expected
ShardingDefinition shardAdd can reference a restricted ManagedJob OpsDefinition: the Cluster controller freezes member/definition/request/Job identities before execution, the Operations controller re-verifies the execution snapshot and live Job identity every round, cleanup is two-phase after success, and every failure/drift/ambiguous-deletion path fails loud with no automatic replay. One managed group at a time; subsequent scale-out/scale-in defers until the active group closes. No process exactly-once claim — the worker resumes/no-ops on its token.
Design iteration and contracts are recorded in the team design thread; implementation follows in the linked PR.
Problem
Scaling a Redis Cluster from 3 to 4 shards completes the object-level topology quickly, but slot migration duration depends on data volume, network, and disk — it cannot be bounded by the synchronous lifecycle action's 60s clamp.
Observed field case (Redis 5.0.12, chart redis-1.2.0-alpha.5): topology reached 8 nodes / 4 masters / 16384 slots within 28s after scale-out, but 29 consecutive checks over 420s never closed and the Cluster stayed Updating. The original migration command logs had rotated, so the evidence proves the synchronous shardAdd action failed to reliably close the long migration; it does not prove a specific timeout root cause (runtime N=1, scoped observation).
The public contract today only promises a synchronous shardAdd action; there is no managed long-task contract. The inline action has no persistent execution identity, no recoverable Job, and no terminal evidence — controller restarts, lost status confirmations, object replacement, or definition drift can strand the scale-out or risk blind replay of a global, non-idempotent migration.
Expected
ShardingDefinition shardAdd can reference a restricted ManagedJob OpsDefinition: the Cluster controller freezes member/definition/request/Job identities before execution, the Operations controller re-verifies the execution snapshot and live Job identity every round, cleanup is two-phase after success, and every failure/drift/ambiguous-deletion path fails loud with no automatic replay. One managed group at a time; subsequent scale-out/scale-in defers until the active group closes. No process exactly-once claim — the worker resumes/no-ops on its token.
Design iteration and contracts are recorded in the team design thread; implementation follows in the linked PR.