User Story
As an OpenShell operator, I want sandbox status to distinguish an intentional shutdown from a runtime interruption, so that stopped sandboxes are not presented as having restarted unexpectedly and real runtime restarts remain recoverable.
Problem Statement
The Docker and Podman drivers currently classify exits 137 (SIGKILL) and 143 (SIGTERM) as ContainerRuntimeRestart. Those codes establish only that a process was terminated by a signal; they do not identify the sender or intent. An explicit gateway stop that forwards SIGTERM therefore produces the same condition as a Podman/Docker machine or daemon restart.
The durable Stopping phase now prevents that ambiguity from promoting an in-flight explicit stop to Error, but a delayed watcher snapshot can still arrive after Stopped is persisted and replace the user-visible status reason with ContainerRuntimeRestart.
Impact / Why This Matters
Operators can see a sandbox in Stopped phase with a contradictory runtime-restart condition after a normal stop. More broadly, treating all 137/143 exits as runtime restarts conflates graceful stop, forced timeout kill, external intervention, and genuine runtime interruption. The current workaround is to infer intent from lifecycle phase, which protects the immediate flow but does not make the driver status semantically precise.
Acceptance Criteria
Reproduction Steps
- Start a Docker- or Podman-backed sandbox.
- Stop it through the gateway so the supervisor forwards SIGTERM to its workload.
- Observe the driver report exit 143 as
ContainerRuntimeRestart.
- Deliver that watcher snapshot after the gateway has persisted
Stopped.
- Observe the sandbox phase remain
Stopped while its condition reason no longer reflects the intentional stop.
Environment
Agent Investigation
ContainerRuntimeRestart is currently a heuristic for exit 137/143 in both Docker and Podman. The exit status has no provenance, so operation intent and independently observed runtime state must be considered separately.
User Story
As an OpenShell operator, I want sandbox status to distinguish an intentional shutdown from a runtime interruption, so that stopped sandboxes are not presented as having restarted unexpectedly and real runtime restarts remain recoverable.
Problem Statement
The Docker and Podman drivers currently classify exits 137 (SIGKILL) and 143 (SIGTERM) as
ContainerRuntimeRestart. Those codes establish only that a process was terminated by a signal; they do not identify the sender or intent. An explicit gateway stop that forwards SIGTERM therefore produces the same condition as a Podman/Docker machine or daemon restart.The durable
Stoppingphase now prevents that ambiguity from promoting an in-flight explicit stop toError, but a delayed watcher snapshot can still arrive afterStoppedis persisted and replace the user-visible status reason withContainerRuntimeRestart.Impact / Why This Matters
Operators can see a sandbox in
Stoppedphase with a contradictory runtime-restart condition after a normal stop. More broadly, treating all 137/143 exits as runtime restarts conflates graceful stop, forced timeout kill, external intervention, and genuine runtime interruption. The current workaround is to infer intent from lifecycle phase, which protects the immediate flow but does not make the driver status semantically precise.Acceptance Criteria
Stoppedwhen a late Docker or Podman signal-exit snapshot arrives, and its terminal status continues to report the intentional stop.Reproduction Steps
ContainerRuntimeRestart.Stopped.Stoppedwhile its condition reason no longer reflects the intentional stop.Environment
Agent Investigation
ContainerRuntimeRestartis currently a heuristic for exit 137/143 in both Docker and Podman. The exit status has no provenance, so operation intent and independently observed runtime state must be considered separately.