microsoft/autogen · error · ValueError

Timeout must be greater than or equal to 1.

Error message

Timeout must be greater than or equal to 1.

What it means

AzureContainerCodeExecutor.__init__ validates its timeout parameter and raises ValueError when timeout < 1. The timeout (seconds) is forwarded to the Azure Container Apps job that actually executes code, and the service rejects sub-second timeouts — so the constructor fails fast instead of surfacing an opaque API error later.

Source

Thrown at python/packages/autogen-ext/src/autogen_ext/code_executors/azure/_azure_container_code_executor.py:109

    def __init__(
        self,
        pool_management_endpoint: str,
        credential: TokenProvider,
        timeout: int = 60,
        work_dir: Union[Path, str, None] = None,
        functions: Sequence[
            Union[
                FunctionWithRequirements[Any, A],
                Callable[..., Any],
                FunctionWithRequirementsStr,
            ]
        ] = [],
        functions_module: str = "functions",
        suppress_result_output: bool = False,
        session_id: Optional[str] = None,
    ):
        if timeout < 1:
            raise ValueError("Timeout must be greater than or equal to 1.")

        self._work_dir: Optional[Path] = None
        self._temp_dir: Optional[tempfile.TemporaryDirectory[str]] = None

        # If a user specifies a working directory, use that
        if work_dir is not None:
            if isinstance(work_dir, str):
                self._work_dir = Path(work_dir)
            else:
                self._work_dir = work_dir
            # Create the directory if it doesn't exist
            self._work_dir.mkdir(exist_ok=True, parents=True)
        # If a user does not specify a working directory, use the default directory (tempfile.TemporaryDirectory)
        else:
            self._temp_dir = tempfile.TemporaryDirectory()
            temp_dir_path = Path(self._temp_dir.name)
            temp_dir_path.mkdir(exist_ok=True, parents=True)

View on GitHub (pinned to 027ecf0a37)

Solutions

  1. Set timeout to at least 1 second, practically 30-600 s for real workloads
  2. Guard your config loader: timeout = max(1, int(cfg.get('timeout', 60)))
  3. Treat 0 in config as 'use default' and substitute the default instead of passing it through

Example fix

# before
executor = AzureContainerCodeExecutor(pm_client, acr_client, resource_group, subscription_id, acr_name, timeout=cfg.get('timeout', 0))

# after
executor = AzureContainerCodeExecutor(pm_client, acr_client, resource_group, subscription_id, acr_name, timeout=max(1, cfg.get('timeout', 60)))
Defensive patterns

Strategy: validation

Validate before calling

def valid_timeout(t) -> int:
    return max(1, int(t)) if t else 60

Prevention

When it happens

Trigger: Constructing AzureContainerCodeExecutor(pool_management_client, acr_client, ..., timeout=0) or a fractional timeout like 0.5, often from a config default of 0 or a computed value that ended up zero.

Common situations: Config files where timeout defaults to 0 meaning 'unset', arithmetic that computes timeout - safety_margin and goes below 1, copying a LocalCommandLineCodeExecutor config that allowed smaller values.

Understand the failure class

Related errors


AI-assisted analysis of microsoft/autogen@027ecf0a37 (2026-08-15). Data as JSON: /api/errors/00a4e47a0e5caa80. Report an issue: GitHub.