Skip to content

fix: recreate a missing managed runtime from the recorded bundle in setup - #42

Merged
rogerdigital merged 1 commit into
mainfrom
fix/setup-recreate-missing-runtime
Sep 20, 2026
Merged

rogerdigital merged 1 commit into
mainfrom
fix/setup-recreate-missing-runtime

Conversation

@rogerdigital

Copy link
Copy Markdown
Owner

The bug

Removing the managed container while state.json and the content-addressed bundle survive leaves setup unrecoverable:

  • setup resolves the deployment as matching (state fields agree, ownership is 'owned' through the surviving volume), readiness times out, and the recovery branch calls docker restart — which refuses when the container is absent: E_STATE_INVALID: Managed Docker resources are incomplete.
  • repair refuses for lack of a profile attachment (remove detached it).
  • remove --service cannot resolve a compose path (it reads com.docker.compose.project.config_files off container labels that no longer exist).

This is exactly the state remove --service without --purge-data leaves (compose down, volume kept), observed live and recorded as finding 6 of the 2026-09-19 baseline window-2 report.

The fix

Setup's matching-unhealthy recovery branch now mirrors the semantics repair's recreate-runtime action already has:

  • container present but wedged → docker restart (unchanged);
  • container absent → recreate the runtime with docker up against the bundle named by the recorded configurationSha256 (bundleComposePath);
  • no recorded digest → refuse with E_STATE_INVALID instead of guessing a compose path.

The subsequent flow (readiness → real search → attach or validate → commit) is unchanged; with no attachment the same recovery runs first, so the original detach-then-cleanup scenario is covered by the same code path.

Deliberately out of scope, recorded as a follow-up: remove --service --purge-data still needs a present container to resolve its compose path, so a full purge after a container-less leftover requires one setup first. Changing what ownership verification means for a destructive command deserves its own discussion.

Verification

  • Two new unit tests in test/cli/setup.test.ts (recreate-from-bundle with the recorded digest, refuse without one); harness deploymentStatus became configurable. All 75 setup tests green; pnpm verify green.
  • Live reproduction on a real managed instance: docker compose down (volume kept) into the exact state that previously failed with Managed Docker resources are incomplete, then the fixed setup recreates the runtime and status --json passes 9/9 checks.

…etup

Removing the container while state and the content-addressed bundle
survive (remove --service without --purge-data, or a manual docker
compose down) left setup unrecoverable: the matching-unhealthy recovery
only knew docker restart, which refuses when the container is absent,
while repair needs a profile attachment and remove --service cannot
resolve a compose path without container labels.

Setup's recovery branch now mirrors repair's recreate-runtime semantics:
when the container is absent, recreate the runtime from the bundle named
by the recorded configurationSha256 (restart unchanged for a wedged but
present runtime); without a recorded digest the deployment is refused
with E_STATE_INVALID instead of guessing a compose path.

Verified against a live reproduction: compose down (volume kept) into a
state that previously failed with 'Managed Docker resources are
incomplete', then setup recreates the runtime and passes all nine status
checks.
@rogerdigital
rogerdigital merged commit dd41438 into main Sep 20, 2026
6 checks passed
@rogerdigital
rogerdigital deleted the fix/setup-recreate-missing-runtime branch September 20, 2026 04:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant