Orphan cleanup

An orphan is a managed relationship whose expected source volume UUID is absent from a complete source observation. Because its destination may contain the only surviving copy, DonkeyFleet never deletes an orphan automatically. manual, approve, and auto modes all require explicit human approval.

Controller-created relationships and explicitly bound adopted relationships participate in this flow. Unbound adopted and suspended relationships are excluded by database queries.

Decision flow

Parameters and gates

Parameter or state	Effect
Automation-profile binding	Grants a previously adopted relationship eligibility for orphan transition and cleanup review; it never grants automatic deletion
max_orphan_transitions_per_run	Absolute per-profile transition limit. If the missing count is greater than the limit, the complete Observe run is rejected and no relationship transitions
max_orphan_transitions_pct	Optional per-profile percentage limit, evaluated with the absolute limit. Exceeding either limit blocks all transitions in that run
orphan_grace_hours	Earliest time a cleanup proposal may be created, measured from persisted orphaned_at
max_actions_per_run	Limits new destination cleanup steps started for a profile in one run; persisted jobs are still polled and recovered
reconcile_mode	Does not change deletion authorization: every mode produces awaiting_approval
Effective dry-run	Blocks both deletion calls even after approval

The transition limits protect against incomplete or unexpectedly broad source visibility loss. They are not deletion limits: they stop the lifecycle transition before any approval is possible.

What approval authorizes

The approval payload freezes the exact source volume UUID, destination volume UUID, SnapMirror relationship UUID, SVM route, orphan timestamp, grace eligibility time, automation profile, and action cap. Apply locks the current relationship and rejects the work if those values no longer match.

After approval and a successful revalidation, DonkeyFleet performs only destination-side work:

1. delete the destination SnapMirror relationship;
2. persist and poll its ONTAP job until observation confirms it is absent;
3. delete the destination volume with force=false;
4. persist and poll its job until observation confirms it is absent;
5. resolve the cleanup intent and write audit history.

No step writes to the source cluster. If a pod or node stops, PostgreSQL retains the current step and job UUID so another replica continues from the checkpoint instead of starting over.

Irreversible operation

Approval authorizes permanent destination data deletion. Independently verify source identity, retention requirements, and the exact destination before approving. A source that was replaced (same name, new UUID) is detected automatically and reclassified to source_replaced drift rather than an orphan, so it does not reach this queue — still, confirm the destination you are deleting has no live source under a different UUID before approving.