Repository navigation
fix: derive the teardown compose path from state for container-less leftovers - #44
Merged
Merged
Conversation
…eftovers remove --service --purge-data refused to clean up the labeled leftovers of a container-less deployment because both the initial and final checks required a compose path read from container labels, forcing an operator to resurrect the runtime (setup) just to delete it. When the container is absent, the teardown path now comes from the bundle recorded in state (configurationSha256); without a recorded digest removal still refuses rather than guessing. Verified live: remove --service (container down, volume kept) followed by remove --service --purge-data --yes purges the volume and managed directory — a sequence that previously failed with E_REMOVE_BLOCKED — and a fresh setup restores a 9/9 healthy deployment.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The bug
remove --service --purge-datarequired a compose path read from container labels in both its initial and final ownership checks. With the container gone (the leftover ofremove --servicewithout--purge-data, or a manualdocker compose down) both checks fail withE_REMOVE_BLOCKED, so fully purging required first resurrecting the runtime withsetup— delete-by-first-creating. This was the follow-up deliberately left open in #42.The fix
When the inspected status has no container, the teardown compose path is derived from the bundle recorded in state (
configurationSha256→config-<sha>/compose.yml), the same derivation repair'srecreate-runtimeand setup's runtime-recovery use. Ownership requirements are unchanged: the leftover resources must still be labeled as ours (ownership: 'owned'), and without a recorded digest removal still refuses rather than guessing a path. A bundle deleted from disk fails closed through Compose's own file check.The
ownership === 'absent'refusal is unchanged: with nothing left to tear down, the mistake-guard still applies.Verification
pnpm verifygreen.remove --service(container down, volume kept) →remove --service --purge-data --yespurges the exact owned volume and the managed directory — the sequence that previously failed — and a freshsetuprestores a 9/9 healthy instance.