The `shell` and `http_request` built-in tools are the only two whose
execution actually honors the tool agent's `timeout` config field
(ToolAgent._execute_shell_command, ToolAgent._http_request_tool), but
their LLM-facing schemas (_BUILTIN_TOOL_SCHEMAS in llm_tools.py) never
told the model a timeout applied, and neither tool's timeout error
named the config field that controls it.
- _BUILTIN_TOOL_SCHEMAS["shell"] and ["http_request"] descriptions now
state that execution is bounded by the agent's configured `timeout`
(seconds), matching the existing precedent of documenting `file_read`'s
`max_chars` behavior in its schema.
- _execute_shell_command's timeout ExecutionError now names `timeout`
as the adjustable config field, in addition to the elapsed seconds it
already reported.
- _http_request_tool now catches asyncio.TimeoutError distinctly from
the generic `except Exception`, so a request timeout produces a
message naming the config field instead of the previous generic
"HTTP request failed" text (which gave no indication a timeout was
the cause). Non-timeout HTTP failures are unaffected — same
exception handling, same message shape as before.
No change to enforcement mechanics: `self.timeout` remains the sole
config field (default 1s, Actor Configuration Standard §4.5). This is
schema/message content only, within the extension precedent already
established by ADR-2030 (D-1 schema registry, D-4/D-6 error-quality
improvements) — no new ADR was needed for this change.
Tests: extended features/tool_agent.feature (updated the two existing
shell/http_request timeout scenarios to also assert the new config-field
hint) and features/llm_tools_coverage.feature (new scenarios asserting
both schema descriptions mention the timeout budget). Full suite:
141 features / 2782 scenarios / 13172 steps passed; coverage 96.8%
(>=96.5% threshold). Robot integration_tests: 27/27 suites passed.
ASV benchmark_regression: no significant change, as expected for a
messaging-only change.
ISSUES CLOSED: #82
The `benchmark` and `benchmark_regression` nox sessions existed and
were fully functional (asv.conf.json configured, benchmarks/ populated),
but neither was ever invoked by any CI workflow — only Robot Framework
integration_tests was actually wired in and required for merge.
Adds a `benchmark` job running `nox -s benchmark_regression` (asv
continuous against origin/master). Requires fetch-depth: 0 plus an
explicit fetch of origin/master, since the other jobs' shallow/ref-only
checkout wouldn't have that ref available for the diff.
Deliberately NOT added to status-check's required job list: a local run
of benchmark_regression took ~15 minutes end-to-end (69 benchmarks x 2
commits x repeated timing rounds for statistical confidence), which is
too slow to gate every merge. continue-on-error: true and the nox
session's own success_codes=[0, 2] keep it non-blocking; results are
still uploaded as an artifact for manual inspection, matching the
project's stated intent for benchmark checks to be informational.
Refs: #82
CoreRasurae
CoreRasurae