abhigyanpatwari/GitNexus · error · ManagedProcessError

managed command failed ({result.state}, exit={result.returnc

Error message

managed command failed ({result.state}, exit={result.returncode}): {result.detail or result.stderr_tail[-1000:]}

What it means

run_checked wraps run_managed: if result.ok is False (state != 'exited' OR returncode != 0) it raises ManagedProcessError, embedding command, full ManagedProcessResult, state, exit code, and either the recorded detail or the last 1000 chars of stderr. This is the canonical 'subprocess failed' signal for callers that want exceptions instead of result inspection.

Source

Thrown at eval/workflow_bench/process_control.py:731

    cleanup = f"{type(error).__name__}: {error}"
    detail = f"{result.detail}; cleanup: {cleanup}" if result.detail else f"cleanup: {cleanup}"
    return replace(
        result,
        state="cleanup-failure",
        primary_state=result.primary_state or result.state,
        detail=detail,
    )


def run_checked(
    command: Sequence[str] | str,
    **kwargs: object,
) -> ManagedProcessResult:
    """Run a managed command and raise with its bounded evidence on failure."""

    result = run_managed(command, **kwargs)  # type: ignore[arg-type]
    if not result.ok:
        raise ManagedProcessError(command, result)
    return result

View on GitHub (pinned to d540b00184)

Solutions

  1. Inspect exc.result: state, returncode, stdout_tail, stderr_tail, detail, primary_state give the actual cause.
  2. If you want to tolerate non-zero exits, call run_managed and check result.ok yourself rather than run_checked.
  3. For ownership-failure details, read result.detail — it tells you whether it was Windows-PID, missing Bubblewrap, etc.
  4. Increase timeout or fix the underlying command based on stderr_tail.

Example fix

// before
run_checked(['git','fetch'], timeout=10)
// after
res = run_managed(['git','fetch'], timeout=60)
if not res.ok:
    log.warning('fetch failed: %s', res.stderr_tail[-500:])
    # fall back / continue
Defensive patterns

Strategy: try-catch

Validate before calling

# Decide up-front whether you can tolerate failure.
result = run_managed(cmd, timeout=60)
if result.ok:
    use(result)
else:
    log.warning('cmd failed state=%s rc=%s detail=%s', result.state, result.returncode, result.detail)
# Only call run_checked if you want an exception on the not-ok branch.

Type guard

from workflow_bench.process_control import ManagedProcessResult

def is_ok_result(r: ManagedProcessResult) -> bool:
    return r.state == 'exited' and r.returncode == 0

Try / catch

from workflow_bench.process_control import ManagedProcessError

try:
    run_checked(cmd, timeout=60)
except ManagedProcessError as exc:
    r = exc.result
    log.error('cmd=%s state=%s rc=%s', exc.command, r.state, r.returncode)
    log.error('stderr tail: %s', r.stderr_tail[-500:])
    if r.state == 'timed-out':
        increase_timeout_or_split()
    elif r.state == 'ownership-failure':
        fix_environment(r.detail)
    raise

Prevention

When it happens

Trigger: Any run_checked invocation where the child exits non-zero, times out (state='timed-out'), is force-killed ('forced-kill'), or fails ownership ('ownership-failure'). The message format string exposes whichever of detail / stderr_tail is non-empty.

Common situations: git command failing on bad ref / network; tool under test exits 1; timeout exceeded; PID namespace / Bubblewrap not available -> ownership-failure; command not found (state still 'exited' with non-zero).

Related errors


AI-assisted analysis of abhigyanpatwari/GitNexus@d540b00184 (2026-08-12). Data as JSON: /api/errors/6b4360654baf17d9. Report an issue: GitHub.