Skip to content

bug(docker): deleting a sandbox while it is starting fails with "volume is in use" #5459

Open

Description

@matthewgrossman

User Story

I run the OpenShell conformance suite against a Docker gateway in CI. I hit this when a test deleted sandboxes it had just created, before they were Ready. I need delete to work in any phase so that cancelling a create, or cleaning up after a failed one, doesn't fail and leave resources behind.

Problem Statement

On the Docker compute driver, deleting a sandbox while it is still starting can fail with an internal error:

gateway error (13): delete sandbox failed: remove Docker sandbox runtime volume: Docker responded with status code 409: remove openshell-supervisor-<id>: volume is in use - [<container id>]

Deleting a sandbox is valid in any phase, so the gateway should finish the delete instead of returning an internal error.

Impact / Why This Matters

  • A user who cancels or deletes a sandbox right after creating it gets an internal error.
  • The sandbox's Docker resources are probably left behind: the volume, and the container that holds it.
  • Automation that creates and deletes sandboxes quickly, such as test cleanup, fails intermittently.
  • The only workaround is to wait for Ready before deleting. That doesn't help when the sandbox never becomes Ready.

Acceptance Criteria

  • Deleting a Docker sandbox in the Provisioning phase succeeds, and the sandbox then disappears from sandbox list.
  • After that delete, no OpenShell containers or volumes for the sandbox remain in Docker.
  • A conformance test creates a sandbox, deletes it without waiting for Ready, and checks that it is gone. The test passes on every driver.

Reproduction Steps

  1. Start a gateway with the Docker compute driver.
  2. Create three sandboxes with sleep infinity as the command, and don't wait for any of them to be Ready.
  3. Delete each one right away.
  4. Some deletes fail with the error above.

In CI this failed on all three Docker e2e lanes (rust-docker, rust-docker-push, additional-ca) of run 42867395409. The test was labels::labels_are_stored_and_filter_list in #5431 at commit a96df3a, before that test was changed to wait for Ready. The same test passed locally against Docker Desktop, so the failure depends on timing.

Environment

Agent Investigation

This is a hypothesis; it hasn't been reproduced in isolation. In crates/openshell-driver-docker/src/lib.rs, delete_sandbox_inner does this:

  1. It aborts the pending provisioning task.
  2. It finds no managed container yet.
  3. It removes the sandbox's volumes.

Aborting the task doesn't cancel a Docker create request that is already in flight. So Docker can still create a container that mounts the supervisor volume, and removing the volume then fails with 409. The error names the container that holds the volume, which fits this explanation. remove_docker_volume turns that 409 into Status::internal.

#5321 (provisioning and bootstrap timeouts) landed just before these runs. It may have changed startup timing, but it hasn't been shown to cause this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions