FLO-27: Stale Supervisor Uuid Bricks Recovery Calls

[liobrasil]

Severity: Low

Files Affected

• cadence/contracts/FlowALPRebalancerPaidv1.cdc
• cadence/contracts/FlowALPSupervisorv1.cdc

Description

The intended stop flow is FlowALPSupervisorv1.Supervisor.removePaidRebalancer(uuid) followed by FlowALPRebalancerPaidv1.RebalancerPaid.delete() (or admin removal). In code, RebalancerPaid.delete() calls FlowALPRebalancerPaidv1.removePaidRebalancer(uuid:), which destroys the stored FlowALPRebalancerv1.Rebalancer, while the Supervisor continues to iterate its paidRebalancers set and calls FlowALPRebalancerPaidv1.fixReschedule(uuid:) for every UUID each tick. However, the system does not enforce the invariant that a deleted paid rebalancer UUID is removed from the Supervisor set, and FlowALPRebalancerPaidv1.fixReschedule(uuid:) force-unwraps borrowRebalancer(uuid)!. Once a UUID becomes stale, the next Supervisor call will panic when it reaches that UUID, reverting the entire array call and preventing recovery attempts for the remaining UUIDs in that run until an admin removes the stale UUID from the Supervisor set. This could lead to a limited denial-of-service on recovery where supervisor call fail repeatedly as long as the stale UUID remains registered, delaying rescheduling for other paid rebalancers and increasing operational burden until the stale entry is pruned. This could be an issue for users expecting their position to be rebalanced on time.

Recommendation

Make fixReschedule non-panicking when the UUID is missing and/or have Supervisor.executeTransaction isolate per-UUID failures so one stale entry cannot revert the whole call.

---

Parent Issue: #209