feat(reconcile): model volume recreation in the plan

[ndeloof]

What I did

Move volume divergence detection and recreation out of the imperative
pre-reconcile path (ensureVolume/removeDivergedVolume) into the
reconciliation plan, activating the dormant planRecreateVolume seam.

A diverged volume now produces an explicit, forward-only plan:
stop → remove containers → remove volume → create volume → create containers.
Container re-creation is delegated to reconcileContainers (affected
services are cleared from the observed snapshot so they are scheduled
fresh, gated on the CreateVolume node), and the recreation cascades to
namespace/volume-sharing dependents.

User confirmation ("recreate, data will be lost") is consulted while
building the plan via reconciler.prompt; declining leaves the volume
untouched. Behavior otherwise matches the previous ensureVolume (no
recreation for a volume with no recorded config-hash, external volumes
validated up front).

Adds an exhaustive reconcile test suite for the volume lifecycle and its
interaction with services (single/scale-N/multi-service recreation,
decline, missing hash, prompt message/error, container mounting several
diverged volumes, partial confirmation, dependent cascade, unmounted
volume) plus an executor test driving the destructive sequence end to end.

Related issue

🤖 Generated with Claude Code

[docker-agent]

Assessment: 🟢 APPROVE

The PR successfully moves volume divergence detection and recreation from the imperative pre-reconcile path (ensureVolume/removeDivergedVolume) into the reconciliation plan. The reconcileVolumes/planRecreateVolumes structure is sound: it collects diverged volumes, gates on user confirmation, stops and removes affected containers in dependency order, removes then recreates volumes, and hands container re-creation to reconcileContainers. The stoppedByPlan deduplication correctly prevents double-stops when a container is shared between network and volume recreation paths. The test suite is comprehensive.

Lower-confidence findings (not posted inline)

• [low] pkg/compose/reconcile.go:114 — observedContainersByService snapshot not updated after containers cleared for volume recreation (confidence: 🟠 weak 52/100)
  r.observed.Containers[svc] is set to nil at line 371 when services are cleared for volume re-creation, but r.observedContainersByService (built once at reconciler init via observed.containersByService()) still holds old containers for those services. When serviceHashWithResolvedRefs is called for a volumes_from dependent of a recreated service, it resolves old container IDs from the stale snapshot. In practice, parentNamespaceRecreated catches this case and forces recreation regardless of hash, so no incorrect decision is made on the happy path — but the two data structures are now diverged, which is a latent inconsistency worth noting for future maintainers.

• [medium] pkg/compose/reconcile.go:371 — volumes_from dependents may not have correct creation ordering after owner service volume recreation (confidence: 🟠 weak 45/100)
  When service B is cleared for volume recreation (r.observed.Containers[B] = nil, r.recreatedServices[B] = true), a dependent service A with volumes_from: [B] is NOT cleared from observed state. reconcileContainers correctly forces recreation of A via parentNamespaceRecreated, but whether A's new container creation node depends (transitively) on the CreateVolume → CreateContainer(B) chain depends on whether infrastructureDeps(A) captures r.serviceNodes[B]. If it does (likely given topological processing order), ordering is correct. If not, A could start before B's fresh container is ready. The verifier rated this speculative without seeing infrastructureDeps internals.

[ndeloof]

Thanks for the review. Adjudication of the two findings, plus a related issue they surfaced — addressed in 72f540c.

[medium] volumes_from creation ordering — not a bug for loaded projects. compose-go normalization injects an implicit depends_on for volumes_from (loader/normalize.go), exactly as it does for network_mode/ipc/pid: service:x. infrastructureDeps consumes service.DependsOn, so the dependent's fresh container is transitively ordered after CreateVolume → CreateContainer(owner). Verified end to end; the cascade test now asserts the full plan ordering rather than substrings.

[low] observedContainersByService staleness — intentional, not an inconsistency to fix. That snapshot backs config-hash resolution (serviceHashWithResolvedRefs) and must mirror the state the executor hashed against at create time; clearing observed.Containers is purely a scheduling concern carried by the plan's dependency edges. Added a comment at the clearing site so the divergence isn't "fixed" by a future maintainer.

Real issue surfaced by this review — servicesUsingVolume only matched services mounting the volume directly, so a volumes_from consumer was not removed before RemoveVolume. Docker materializes the inherited mount on the consumer's container, so the removal would have failed with "volume in use" (the previous imperative removeDivergedVolume had the same blind spot). Fixed by computing the transitive volumes_from closure; a dedicated test now guards the RemoveVolume → RemoveContainer(consumer) edge.

Also reassigned the result of Labels.Add in createVolume (it mutates in place only when the map is non-nil).

[glours]

Two edge regressions from the switch to label-filtered observed state, both verified against the old ensureVolume path:

• A same-named volume created manually or by another project used to be reused with just a warning (inspect by name). It's now invisible to the observed state, so we plan a VolumeCreate on every up: hard failure if the driver differs, spurious
  Creating/Created events forever otherwise. checkVolumes should probably inject those unlabeled-but-existing volumes into the observed state, like it already does for externals.

• Renaming a volume now hits the diverged path: the old volume is matched by label and VolumeHash includes Name, so with up -y we delete the old volume and its data, where we previously just created the new one and left the old untouched. The
  prompt also names the new volume, which doesn't exist yet. When observed.Name != desired.Name I'd keep the additive behavior, or at least prompt with the name of the volume we're about to delete.

[ndeloof]

Thanks @glours, both fixed in 2ba485b.

1. Unlabeled/foreign same-named volume — collectObservedState now discovers volumes by name when the label filter misses them, recording them as unmanaged matches with an empty config-hash, so the reconciler reuses them untouched (no spurious VolumeCreate). Warnings kept via warnUnmanagedVolumes; checkVolumes shrinks to external-only validation.

2. Volume rename — when observed.Name != desired.Name, the new volume is created additively and the old one is left untouched, with no prompt (no more data loss under up -y, no more prompt naming a not-yet-existing volume).

[codecov]

Codecov Report

❌ Patch coverage is 93.19728% with 10 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
pkg/compose/reconcile.go	95.83%	2 Missing and 2 partials ⚠️
pkg/compose/create.go	90.62%	2 Missing and 1 partial ⚠️
pkg/compose/observed_state.go	84.21%	2 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!

[glours]

LGTM, tests ok 👌

[ndeloof]

Follow-up on the rename case (f16d0bc): the additive fix kept the old name in the observed state, so existing containers stayed on the old volume while fresh replicas mounted the new one (split-brain), and later runs picked a nondeterministic winner between the two equally-labelled volumes.

Now the observed volume name is rewritten to the desired one after planning the renamed create, so reconcileContainers migrates the existing containers onto the new volume within the same up — full parity with the old ensureVolume path — while still leaving the old volume and its data intact. Covered by a targeted test asserting the additive create + container migration (no RemoveVolume, no prompt).