Handle restarting containers in cluster status, logs, and stop #1638

New issue

Closed

opened 2026-08-02 06:22:52 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-02 06:22:52 +00:00

Member

Problem

When a collaboration cluster broker is restarting, Ward cannot inspect or remove the cluster. On v0.868.0 these commands all fail:

ward agent cluster status <cluster-id> --json
ward agent cluster logs <cluster-id> --tail 100
ward agent cluster stop <cluster-id>

Each reports an error shaped like:

unexpected Docker cluster row "<container>\tRestarting (1) ...\t<project>\tbroker\t<harness>"

The failure mode was exposed by a broker startup crash. Direct Docker logs and cleanup were required because Ward's own diagnostic and scoped cleanup surfaces rejected the container state.

Expected behavior

Cluster discovery should recognize valid Docker lifecycle states. A failed or restarting cluster must remain observable and removable through Ward.

Acceptance criteria

Cluster row parsing accepts valid restarting, exited, created, paused, dead, healthy, and unhealthy states emitted by the supported Docker Compose surface.
cluster status --json reports the actual state and health of a restarting or stopped service.
cluster logs reads logs from restarting and exited services.
cluster stop removes exactly the targeted cluster even when one or more services are unhealthy or restarting.
Truly malformed rows still fail closed with a contextual error.
Fixtures cover a Restarting (1) row with spaces and parentheses.
A focused lifecycle test proves diagnosis and cleanup after broker startup failure.
Healthy cluster behavior and project isolation remain unchanged.

#1635
#1636

## Problem When a collaboration cluster broker is restarting, Ward cannot inspect or remove the cluster. On v0.868.0 these commands all fail: ```text ward agent cluster status <cluster-id> --json ward agent cluster logs <cluster-id> --tail 100 ward agent cluster stop <cluster-id> ``` Each reports an error shaped like: ```text unexpected Docker cluster row "<container>\tRestarting (1) ...\t<project>\tbroker\t<harness>" ``` The failure mode was exposed by a broker startup crash. Direct Docker logs and cleanup were required because Ward's own diagnostic and scoped cleanup surfaces rejected the container state. ## Expected behavior Cluster discovery should recognize valid Docker lifecycle states. A failed or restarting cluster must remain observable and removable through Ward. ## Acceptance criteria * Cluster row parsing accepts valid restarting, exited, created, paused, dead, healthy, and unhealthy states emitted by the supported Docker Compose surface. * `cluster status --json` reports the actual state and health of a restarting or stopped service. * `cluster logs` reads logs from restarting and exited services. * `cluster stop` removes exactly the targeted cluster even when one or more services are unhealthy or restarting. * Truly malformed rows still fail closed with a contextual error. * Fixtures cover a `Restarting (1)` row with spaces and parentheses. * A focused lifecycle test proves diagnosis and cleanup after broker startup failure. * Healthy cluster behavior and project isolation remain unchanged. ## Related * #1635 * #1636

coilyco-ops added the

autonomy

headless

priority

labels

2026-08-02 06:23:00 +00:00

coilyco-ops referenced this issue from a commit

2026-08-02 06:44:14 +00:00

fix: manage non-running collaboration clusters

coilyco-ops closed this issue

2026-08-02 06:44:14 +00:00