PR #67897: Agents/image tool: honor tools.media.image.timeoutSeconds (#67889)

• Repository: openclaw/openclaw
• Author: neeravmakwana
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/67897

Description (problem / solution / changelog)

Summary

• Problem: the agent-facing `image` tool hardcoded a 30s abort timeout for every `describeImage`/`describeImages` call, silently overriding the documented `tools.media.image.timeoutSeconds` config. Self-hosted / local vision models (Ollama, etc.) that need longer than 30s got aborted even when operators explicitly set a larger value. Separately, `minimaxUnderstandImage` used a hardcoded `AbortSignal.timeout(60_000)` regardless of caller-supplied timeouts, so the MiniMax VLM path could not pick up the operator's configured value either.
• Why it matters: users following the public docs ("Timeout in seconds for each image understanding request before it is aborted. Increase for high-resolution analysis...") would see their configured timeout ignored by the `image` tool, reproducing #67889.
• What changed:
  • `src/agents/tools/image-tool.ts`: resolve the effective timeout from `cfg.tools.media.image.timeoutSeconds` (falling back to `DEFAULT_TIMEOUT_SECONDS.image` = 60s, via the existing `resolveTimeoutMs` helper) and pass it to every `describeImage` / `describeImages` call instead of the hardcoded `30_000`.
  • `src/media-understanding/image.ts`: forward `params.timeoutMs` into the MiniMax branch (`describeImagesWithMinimax`).
  • `src/agents/minimax-vlm.ts`: accept an optional `timeoutMs` parameter and use it for `AbortSignal.timeout(...)` instead of the hardcoded `60_000` (falls back to 60s when not supplied, preserving existing behavior for any callers that do not plumb a timeout).
• What did NOT change (scope boundary):
  • No config schema, default value, help text, or label changes. `tools.media.image.timeoutSeconds` already existed with a documented 60s default; this PR makes the tool honor what was already documented.
  • No public Plugin SDK surface changes.
  • No network, fs, sandbox, permission, or model-selection behavior changes.
  • The auto-attachment image-understanding path (`src/media-understanding/runner.entries.ts`) already honored this config — unchanged here.

Change Type (select all)

• Bug fix

Scope (select all touched areas)

• Skills / tool execution

Linked Issue/PR

• Closes #67889
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: `src/agents/tools/image-tool.ts` threaded a hardcoded `timeoutMs: 30_000` into all three `describeImage`/`describeImages` call sites, completely bypassing `cfg.tools.media.image.timeoutSeconds`. Additionally, `src/agents/minimax-vlm.ts` used `AbortSignal.timeout(60_000)` regardless of caller input, so even if a caller had wanted to override the MiniMax branch's timeout it had nowhere to flow.
• Missing detection / guardrail: no test asserted that `tools.media.image.timeoutSeconds` flowed through to the tool's underlying `describeImage`/`describeImages` calls. The existing image-tool tests covered model selection, sandbox, workspace policy, and MiniMax routing, but not timeout plumbing.
• Contributing context: the auto-attachment path (`runner.entries.ts`) did honor the config correctly via `resolveTimeoutMs`, which hid the tool-side divergence from casual inspection.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
• Target test or file: `src/agents/tools/image-tool.test.ts`
• Scenario the test should lock in: the effective `timeoutMs` passed into the mocked `describeImageWithModel`/`describeImagesWithModel` (and into `AbortSignal.timeout` on the MiniMax path) matches `cfg.tools.media.image.timeoutSeconds` (with the 60s default when unset, and the 1000ms floor from `resolveTimeoutMs`).
• Why this is the smallest reliable guardrail: captures timeout at the exact seam where the bug lived (tool → describe call site, and minimax helper → `AbortSignal.timeout`). No network, no vision model, no fake timers.

Added tests:

• `describe("image tool timeout configuration (#67889)")` — 4 cases:
  • default (no config) → 60,000 ms (aligned with `DEFAULT_TIMEOUT_SECONDS.image`)
  • `tools.media.image.timeoutSeconds: 180` single-image → 180,000 ms
  • `tools.media.image.timeoutSeconds: 300` multi-image → 300,000 ms
  • sub-second value (`0.2`) clamps to the `resolveTimeoutMs` 1000 ms floor
• `describe("minimaxUnderstandImage timeout plumbing (#67889)")` — 3 cases:
  • explicit `timeoutMs` → used verbatim on `AbortSignal.timeout`
  • no `timeoutMs` → 60,000 ms default
  • non-finite / non-positive `timeoutMs` → 60,000 ms default

User-visible / Behavior Changes

• Operators who set `tools.media.image.timeoutSeconds` now see that value respected by the `image` tool (including the MiniMax VLM branch), matching the existing docs and the already-correct auto-attachment path.
• Default timeout for the `image` tool changes from the previously-hardcoded 30s to `DEFAULT_TIMEOUT_SECONDS.image` (60s), aligning with the image-understanding default used elsewhere in the system. Admins who want a tighter cap can set `tools.media.image.timeoutSeconds` to the desired number of seconds (minimum 1s floor).

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No (same outbound calls, only the wall-clock timeout before they abort changes)
• Command/tool execution surface changed? No (same tool surface, same fs/sandbox/workspace policy)
• Data access scope changed? No
• Security/runtime controls unchanged by this PR:
  • Trusted local `MEDIA:` tool-result passthrough and built-in tool name collision enforcement (unchanged).
  • Image tool sandbox, workspace, and `tools.fs.workspaceOnly` policy (unchanged — existing image-tool tests covering these still pass).
  • Remote URL blocking in sandboxed image tool (unchanged).
  • Auth / model selection / provider registry (unchanged).
  • Timeout enforcement itself remains runtime-enforced via `resolveTimeoutMs` → `setTimeout` / `AbortSignal.timeout`, never derived from prompt text; the admin-controlled config value is the source of truth.

Repro + Verification

Environment

• OS: macOS (any); also applies to Linux/Windows
• Runtime/container: Node 22+, `pnpm`
• Model/provider: any vision model (issue reported with a local Ollama model; also affects MiniMax VLM)
• Integration/channel (if any): N/A (reproduces directly through the `image` agent tool)
• Relevant config (redacted): `tools.media.image.timeoutSeconds: <any value > 30>`, e.g. `180`

Steps

1. Configure `tools.media.image.timeoutSeconds: 180`.
2. Have the agent invoke the `image` tool against a model whose first-byte latency exceeds 30s (e.g. a large local vision model).

Expected

• The request is aborted only after the configured 180s timeout.

Actual (before this PR)

• The request is aborted after ~30s regardless of the configured value.

Evidence

• Failing test/log before + passing after — added regression tests fail against the old hardcoded timeouts and pass against the new implementation (`pnpm test src/agents/tools/image-tool.test.ts -t "#67889"`: 7 passed).

Human Verification (required)

• Verified scenarios:
  • `pnpm test src/agents/tools/image-tool.test.ts` — 42 passed, 0 failed.
  • `pnpm test src/media-understanding/image.test.ts` — 5 passed, 0 failed.
  • `pnpm lint` on touched files — clean (remaining lint errors are in unrelated `extensions/qa-lab/src/providers/aimock/server.ts`, pre-existing on `origin/main`).
  • `pnpm tsgo` on touched files — clean (same pre-existing `aimock` errors on `origin/main`, unrelated).
  • `pnpm format` — clean on touched files.
• Edge cases checked:
  • Unset config → 60s default.
  • `timeoutSeconds: 0.2` → clamped to 1000ms floor by `resolveTimeoutMs`.
  • MiniMax branch with no `timeoutMs` supplied → still 60s default (existing behavior preserved for any other callers).
  • MiniMax branch with non-finite / non-positive `timeoutMs` → falls back to 60s default (hardening).
• What I did not verify:
  • Full `pnpm test` suite (long runtime; CI covers it).
  • Full `pnpm check` (blocked by pre-existing unrelated failures on main).
  • Live end-to-end run against a real slow local vision model (the regression tests directly capture the timeout value at the seam that failed, which is the exact source of the bug).

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes — configs without `tools.media.image.timeoutSeconds` now get the documented 60s default (previously the tool silently capped at 30s).
• Config/env changes? No
• Migration needed? No

Risks and Mitigations

• Risk: users who implicitly depended on the old 30s cap see image-tool calls run up to 60s by default.
  • Mitigation: the 60s default matches the already-documented capability default used everywhere else in media understanding; admins who want a stricter cap can set `tools.media.image.timeoutSeconds` explicitly (with a 1s floor).

Made with Cursor

Changed files

• CHANGELOG.md (modified, +1/-0)
• src/agents/minimax-vlm.ts (modified, +17/-1)
• src/agents/tools/image-tool.test.ts (modified, +176/-0)
• src/agents/tools/image-tool.ts (modified, +21/-3)
• src/media-understanding/image.ts (modified, +4/-0)

---

PR #67929: fix(image): respect configured timeout on MiniMax VLM fallback path

• Repository: openclaw/openclaw
• Author: alchip
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/67929

Description (problem / solution / changelog)

Summary

• add optional timeoutMs to minimaxUnderstandImage
• use configured timeout (with 60s default fallback) instead of always forcing 60s
• pass image-tool timeout through MiniMax VLM fallback path
• add regression test for custom timeout propagation

Why

The image understanding tool currently ignores configured tools.media.image.timeoutSeconds on the MiniMax VLM path due to a hardcoded AbortSignal.timeout(60_000).

Fixes #67889

Testing

• ./node_modules/.bin/vitest src/agents/minimax-vlm.normalizes-api-key.test.ts src/media-understanding/image.test.ts

Changed files

• extensions/imessage/src/monitor/inbound-processing.test.ts (modified, +27/-0)
• src/agents/minimax-vlm.normalizes-api-key.test.ts (modified, +24/-0)
• src/agents/minimax-vlm.ts (modified, +8/-1)
• src/media-understanding/image.ts (modified, +4/-0)