Dry-Run Reclamation Report¶
Preview report — instantiates Reachability-Guided Resource Reclamation
Computes exactly what would be reclaimed and reports it for review without deleting anything, so the delete-list can be approved before it runs.
Dry-Run Reclamation Report runs the whole reclamation computation but stops one step short of acting: it produces the exact list of resources it would free, annotated with why each was judged unreachable, and hands that manifest to a human for approval instead of deleting anything. Where the other reclaimers act on their own verdict, this one separates deciding from doing, inserting a review gate between them. Its output is a concrete, actionable artifact — a delete-list plus the reasoning and the blast radius — and, once approved, that same document becomes the before-image you can roll back against. The mechanism's whole value is that a reclamation which would be irreversible in production becomes reversible on paper first.
Example¶
An infrastructure team wants to clean up unused cloud resources — old databases, orphaned disks, stale load balancers — but a wrong deletion could take down a live service. They run terraform plan, which compares the declared configuration against what actually exists and prints exactly what an apply would destroy: twelve resources, each with the reason it is slated for removal. Nothing is touched yet. Reviewing the plan, an engineer notices that one "orphaned" volume is still attached by another stack not represented in this configuration; the reachability picture the plan drew was incomplete. They abort, fix the configuration, and re-plan before ever running terraform apply. The report caught a false-positive reclamation before it deleted a volume holding live data — and the approved plan doubles as the record of what was authorized.
How it works¶
It performs the reachability computation — a trace, a diff against desired state, or both — entirely in simulation, mutating nothing. From the result it assembles a manifest: the candidate resources, the finding for each (unreachable, orphaned, superseded), and the dependents that would be affected. That manifest is routed to an approver, and only an explicit approval promotes it to an execution. The approved manifest is retained as the authorization-and-rollback record. The defining constraint is that the mechanism never frees a resource itself; it produces the evidence on which a separate execution step will.
Tuning parameters¶
- Manifest granularity — from a bare count to a per-resource dossier with retention paths. More detail supports better review but buries the reviewer if overdone.
- Blast-radius depth — how many levels of dependents to surface for each candidate. Deeper analysis catches indirect breakage but costs computation and reviewer attention.
- Staleness window — how long an approved manifest stays valid, and whether a re-plan is forced immediately before execution.
- Approval policy — who must sign off, and whether high-blast-radius deletions demand stricter authorization than routine ones.
When it helps, and when it misleads¶
Its strength is catching the reclamation you would regret before it happens: a preview turns an irreversible delete into a reviewable proposal and leaves an audit trail of what was authorized. It misleads through the gap between check and act. A manifest is a snapshot; if the reference graph changes between preview and execution, an approved delete can operate on stale reality and remove something that became reachable in the interim — a classic time-of-check-to-time-of-use hazard.[n1] It can also breed false confidence when the simulation diverges from what execution actually does. The classic misuse is rubber-stamping a large plan without reading it, so the gate exists on paper but not in practice. The guarding discipline is to keep the check-to-act window short — re-plan immediately before applying — and to make the review proportional to the blast radius rather than reflexive.
How it implements the components¶
candidate_reclamation_set— the report's central artifact is precisely the enumerated set of resources that would be reclaimed, made explicit for inspection.reachable_closure_record— for each candidate it records the reachability finding (what still points to it, or why nothing does), so a reviewer can audit the verdict rather than trust it.audit_and_rollback_record— the approved manifest is both the authorization trail and the before-image the eventual execution can be rolled back against.
It implements no reclamation_policy — it never frees anything; carrying the verdict into action belongs to executors like tracing_mark_sweep_cycle and lease_expiry_sweep — and it runs no standing leak_and_retention_monitor, which is reachability_graph_visualization's.
Against its nearest twin reachability_graph_visualization: this mechanism emits a concrete, approvable delete-manifest with a rollback record and a decision gate; that one renders graph structure for open-ended exploration and produces no delete-list.
Related¶
- Instantiates: Reachability-Guided Resource Reclamation — supplies the review-before-act gate that makes irreversible reclamation reversible on paper.
- Consumes: tracing_mark_sweep_cycle — it runs that mechanism's reachability trace in simulation to compute the manifest.
- Sibling mechanisms: reference_counting · generational_collection · concurrent_collection_barrier · cycle_detection_pass · lease_expiry_sweep · reachability_graph_visualization · tombstone_then_delete · weak_reference_registry
Editorial Notes¶
Form Classification¶
Form family: Experiment, Test & Rehearsal
Rationale: Dry-Run Reclamation Report operates as a bounded trial, probe, simulation, or rehearsal that generates evidence from performance because it computes exactly what would be reclaimed and reports it for review without deleting anything, so the delete-list can be approved before it runs.
Independent corroboration: The frozen evidence defines Dry-Run Reclamation Report as 'Computes exactly what would be reclaimed and reports it for review without deleting anything, so the delete-list can be approved before it runs', so its operative form is Experiment, Test & Rehearsal.
Nearest alternative: Analysis, Modeling & Optimization — Running reachability in a no-mutation environment actively tests a deletion candidate and produces evidence before approval.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Systems-administration practice cohered dry-run modes that compute and display proposed deletions or reclamation without mutating state.
Review resolution: Computer science is primary because dry-run deletion previews arose as a recognizable method in software and storage tooling; organizational approval is a later governance layer rather than an independent origin lineage.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Time-of-check-to-time-of-use (TOCTOU) — a class of race in which a condition validated at check time changes before the dependent action runs, so the action operates on stale reality. For a dry-run report, it is the window between approving a manifest and executing it. ↩