Please read this first
- I have read the Agents SDK docs.
- I searched for related issues and did not find one for
Blaxel ExecTimeoutError effective timeout None.
Describe the bug
The Blaxel sandbox resolves an effective execution timeout, but timeout errors are raised with the original timeout argument instead of the resolved value.
In src/agents/extensions/sandbox/blaxel/sandbox.py, _exec_internal() computes:
exec_timeout = self._coerce_exec_timeout(timeout)
but raises:
raise ExecTimeoutError(command=command, timeout_s=timeout, cause=e) from e
The PTY path has the same pattern: it computes exec_timeout = timeout if timeout is not None else self.state.timeouts.exec_timeout_s, but raises ExecTimeoutError(..., timeout_s=timeout, ...).
When callers rely on the default timeout, the resulting ExecTimeoutError can carry timeout_s=None even though a concrete provider timeout was applied.
Debug information
- Agents SDK version: main branch
- Python version: N/A, code inspection
Repro steps
A minimal reproduction can be built by making the underlying Blaxel operation exceed the default timeout while calling session.exec(...) without passing timeout=:
# Pseudocode using a BlaxelSandboxSession whose underlying process.exec stalls
# long enough for asyncio.wait_for(..., timeout=exec_timeout) to raise.
try:
await session.exec("sleep", "999") # no timeout argument; provider default is used
except ExecTimeoutError as exc:
print(exc.timeout_s) # currently can be None instead of the effective default
Code path:
- Open
src/agents/extensions/sandbox/blaxel/sandbox.py.
- Inspect
_exec_internal() around the exec_timeout calculation and except asyncio.TimeoutError block.
- Inspect
pty_exec_start() around the exec_timeout calculation and timeout handler.
- Both timeout handlers pass the original
timeout argument to ExecTimeoutError.
Expected behavior
ExecTimeoutError.timeout_s should report the effective timeout that was actually enforced. For Blaxel this should be exec_timeout in both the normal exec and PTY exec paths.
Please read this first
Blaxel ExecTimeoutError effective timeout None.Describe the bug
The Blaxel sandbox resolves an effective execution timeout, but timeout errors are raised with the original
timeoutargument instead of the resolved value.In
src/agents/extensions/sandbox/blaxel/sandbox.py,_exec_internal()computes:but raises:
The PTY path has the same pattern: it computes
exec_timeout = timeout if timeout is not None else self.state.timeouts.exec_timeout_s, but raisesExecTimeoutError(..., timeout_s=timeout, ...).When callers rely on the default timeout, the resulting
ExecTimeoutErrorcan carrytimeout_s=Noneeven though a concrete provider timeout was applied.Debug information
Repro steps
A minimal reproduction can be built by making the underlying Blaxel operation exceed the default timeout while calling
session.exec(...)without passingtimeout=:Code path:
src/agents/extensions/sandbox/blaxel/sandbox.py._exec_internal()around theexec_timeoutcalculation andexcept asyncio.TimeoutErrorblock.pty_exec_start()around theexec_timeoutcalculation and timeout handler.timeoutargument toExecTimeoutError.Expected behavior
ExecTimeoutError.timeout_sshould report the effective timeout that was actually enforced. For Blaxel this should beexec_timeoutin both the normal exec and PTY exec paths.