Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Three empty catch {} blocks in streaming and proxy paths silently swallow errors that may indicate real I/O failures, stream corruption, or URL parsing errors. Unlike the previously reported pairing/infra catches (#63423, closed), these are in hot paths where swallowed errors can mask stream truncation or connection issues during LLM inference.

Steps to reproduce

1. Open src/agents/tools/web-shared.ts:290 — reader.releaseLock() inside an empty catch {}.
2. Open src/agents/runtime/proxy.ts:412 — reader?.releaseLock() inside an empty catch {}.
3. Open src/agents/minimax-vlm.ts:57 — URL parsing inside an empty catch {} that falls through to default.

Expected behavior

Each catch site should either:

1. Log the error at debug/warn level so stream cleanup failures are traceable during troubleshooting, or
2. Include an explicit comment explaining why the error is intentionally ignored (e.g., // reader already released or stream already closed).

This follows the same pattern established in the pairing/infra cleanup from #63423 where empty catches were classified as intentional fallback vs. unexpected failure.

Actual behavior

src/agents/tools/web-shared.ts:289-290:

try {
  reader.releaseLock();
} catch {}

After a truncated web fetch response, if releaseLock() throws (e.g., stream already released by concurrent cancel), the error is silently swallowed. This can mask a scenario where the response body was only partially read but no diagnostic trace remains.

src/agents/runtime/proxy.ts:411-412:

try {
  reader?.releaseLock();
} catch {}

Same pattern in the proxy SSE stream cleanup. If the proxy stream fails mid-read, the releaseLock error is swallowed. Combined with the catch(() => {}) on reader.cancel() at line 284, proxy stream cleanup has zero observability.

src/agents/minimax-vlm.ts:57:

try {
  return new URL(value);
} catch {}

URL parsing failure silently falls through to a default return. If a user configures a Minimax VLM endpoint with a malformed URL, the error is silently ignored and the default endpoint is used — no diagnostic hint that the configured URL was invalid.

OpenClaw version

2026.6.5

Operating system

macOS 15.4

Install method

pnpm from source

Model

N/A (error handling behavior, not model-specific)

Provider / routing chain

N/A

Logs

Source evidence:

1. src/agents/tools/web-shared.ts:289-290 — empty catch on reader.releaseLock() in readResponseText().
2. src/agents/runtime/proxy.ts:411-412 — empty catch on reader?.releaseLock() in streamProxy().
3. src/agents/minimax-vlm.ts:57 — empty catch in URL constructor, falls through to default.

For comparison, the surrounding code at web-shared.ts:280-281 already uses a descriptive comment pattern:

} catch {
  // Best-effort: return whatever we read so far.
}

But the releaseLock catches at lines 290 and 412 have no such comment, making it unclear whether the swallow is intentional.

Impact and severity

Affected: Users troubleshooting truncated web fetches, proxy stream failures, or misconfigured Minimax VLM endpoints.
Severity: Medium (does not cause data loss but significantly hinders debugging when these paths fail).
Frequency: Intermittent — only surfaces when stream cleanup or URL parsing fails.
Consequence: Troubleshooting stream truncation or proxy errors requires adding ad-hoc logging since the error trace is lost. Minimax VLM misconfiguration silently uses the wrong endpoint.

Additional information

These are distinct from the catches reported in #63423 (pairing-store, setup-code, home-dir, brew, ports-lsof). Those were in setup/infra paths; these are in the agent inference hot path. The #63423 fixes landed commented-intent or debug-logging patterns that could serve as the template for these sites as well.