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
- Set timeout to at least 1 second, practically 30-600 s for real workloads
- Guard your config loader: timeout = max(1, int(cfg.get('timeout', 60)))
- 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
- Clamp user config: timeout = max(1, int(config.get('timeout', 60)))
- Treat 0 as 'unset' and substitute a sane default (60s+)
- Keep executor construction behind one factory that validates all params
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
- Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.
Related errors
- Invalid configuration: {str(e)}
- vector_fields must contain at least one field name for vecto
- vector_fields must contain at least one field name for hybri
- search_fields must contain at least one field name for hybri
- semantic_config_name is required when query_type is 'semanti
AI-assisted analysis of microsoft/autogen@027ecf0a37 (2026-08-15).
Data as JSON: /api/errors/00a4e47a0e5caa80.
Report an issue: GitHub.