fix: configurable compose startup timeout via SHIELDCLAW_COMPOSE_START_TIMEOUT

[Copilot]

CI integration tests were failing because compose services consistently exceeded the hardcoded 120s startup window on GitHub-hosted runners (cold pulls, slow init). Cleanup isolation was also a concern for concurrent runs.

Core change — env-var-driven timeout

DockerOrchestrator.__init__ now accepts start_wait_seconds: float | None = None. When None, the value is resolved at construction time from SHIELDCLAW_COMPOSE_START_TIMEOUT, falling back to 120s:

# Unset → 120 s (module default, raised from 60 s)
orch = DockerOrchestrator()

# CI sets SHIELDCLAW_COMPOSE_START_TIMEOUT=240 → 240 s
orch = DockerOrchestrator()

# Explicit arg still wins regardless of env var
orch = DockerOrchestrator(start_wait_seconds=30.0)

Test fixes

• test_docker_orchestrator_integration.py / test_docker_orchestrator_concurrency.py: removed hardcoded start_wait_seconds=120.0 so CI env var takes effect.
• test_docker_orchestrator_integration.py: added missing @pytest.mark.integration marker — the test was leaking into unit runs and failing due to no attacker image.
• test_docker_orchestrator.py: four new unit tests covering default, env-var override, explicit-arg precedence, and invalid-value fallback.

CI

- name: pytest integration
  env:
    SHIELDCLAW_ATTACKER_IMAGE: shieldclaw-attacker:ci
    SHIELDCLAW_COMPOSE_START_TIMEOUT: "240"

Original prompt

Fix failing CI job 74156731084 by addressing Docker compose startup timeouts and concurrency cleanup in the Docker orchestrator. Use PR #50 as context (head ref claude/focused-varahamihira-bc2b9f).

Requirements:

• Update the Docker orchestrator to allow a configurable compose startup timeout via an environment variable (e.g., SHIELDCLAW_COMPOSE_START_TIMEOUT), defaulting to the current 120 seconds when unset.
• Ensure cleanup operations only target containers labeled for the current run to avoid concurrent run interference.
• Update tests as needed to cover the new timeout configuration behavior.
• If CI configuration needs adjustment, add the env var for integration tests in .github/workflows/ci.yml.
• Rename the branch to a sensible, descriptive name before opening the PR (replace the current claude/focused-varahamihira-bc2b9f).

Use the existing repo structure under shield-claw/ and keep changes minimal and focused on the failure.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: Please find a solution for failing job 74156731084. Use the logs, job definition, and any referenced files where the failure occurred. Keep your response focused on the solution and include code suggestions when appropriate.

Assistant: The failures all stem from Docker compose services not becoming ready within the 120s timeout, which breaks concurrency isolation and the pipeline E2E tests. The logs show SandboxStartError: Timed out after 120.0 seconds waiting for compose services to start. and concurrency cleanup interference. The integration job pulls images and runs Docker-based tests in the CI workflow.

What to change (recommended):

1. Increase the compose startup timeout used by the orchestrator for CI to accommodate cold pulls/slow runners.
2. Gate cleanup by run-specific labels to prevent one run from deleting another run’s containers when startup is slow.

Concrete code suggestions:

• Increase timeout for CI runs (e.g., via env var):

  # .github/workflows/ci.yml
  - name: pytest integration
    if: steps.docker_check.outputs.available == 'true'
    env:
      SHIELDCLAW_ATTACKER_IMAGE: shieldclaw-attacker:ci
      SHIELDCLAW_COMPOSE_START_TIMEOUT: "240"  # new
    run: >-
      pytest -m integration --no-cov -v --timeout=300

• Use the env var in the Docker orchestrator (example patch logic):

  # docker_orchestrator.py
  timeout = float(os.getenv("SHIELDCLAW_COMPOSE_START_TIMEOUT", "120"))
  self._wait_for_compose_ready(timeout=timeout)

• Tighten cleanup to run labels if not already:

  # docker_orchestrator.py
  # Only remove containers with this run's result_id label
  labels={"shieldclaw.result_id": str(result_id)}

Why this fixes it:
The tests fail because the compose stack doesn’t reach “ready” within 120 seconds, which then triggers cleanup and causes concurrency collisions. Allowing a longer startup window and ensuring cleanup only targets containers from the current run prevents the timeouts and cross-run deletion.

User: ok fix it, also change the name of the branch to something that makes sense

Assistant: We’re waiting for your response to the approval prompt before we can continue.

This pull request was created from Copilot chat.

[Copilot]

Pull request overview

This PR makes Docker compose startup readiness waiting configurable via an environment variable to reduce flaky CI integration failures on slow runners.

Changes:

• Add SHIELDCLAW_COMPOSE_START_TIMEOUT support (with module default raised to 120s) and wire it into DockerOrchestrator.__init__ when start_wait_seconds is unset.
• Update integration tests to rely on the env-var timeout (and mark the full-stack test as @pytest.mark.integration).
• Set SHIELDCLAW_COMPOSE_START_TIMEOUT=240 for the integration job in CI.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
shield-claw/src/shieldclaw/sandbox/docker_orchestrator.py	Adds env-var-driven startup wait timeout and updates constructor default behavior.
shield-claw/tests/test_docker_orchestrator.py	Adds unit tests for env var default/override/precedence/invalid parsing.
shield-claw/tests/test_docker_orchestrator_integration.py	Marks the test as integration-only; removes hardcoded timeout to allow CI env var to apply.
shield-claw/tests/test_docker_orchestrator_concurrency.py	Removes hardcoded timeout to allow CI env var to apply.
.github/workflows/ci.yml	Sets SHIELDCLAW_COMPOSE_START_TIMEOUT for integration pytest step.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.