web_search can hang forever instead of failing: one stalled request wedges the whole turn

[akshaytp1571]

web_search can hang forever instead of failing — one stalled request wedges the whole turn

Summary

When the DeepSeek Search/Fetch API endpoint stalls (or the credential resolver behind it never
settles), web_search / web_fetch never return. The turn stays running indefinitely, no
tool/result event is ever appended, and even cancelling does not unwind it — only a process
restart clears it.

Cause: dispatchDeepSeekWeb awaits fetch() directly, and Node's fetch has no default
timeout. The cooperative tool-call timeout policy in dsh-tool-call-timeout-policy can abort
exec.signal, but aborting a signal cannot settle a promise that never settles — so the step
above the tool keeps awaiting it forever.

To be precise about where the gap is, since it is easy to misread this as a missing-timeout bug:
the budget is not missing, it is declared and unenforceable. applyWebSearchTool attaches
timeoutMs = searchTimeoutMs, default 30_000 (packages/web/tool-web/src/index.ts:29 and
:65), and packages/web/tool-web/src/search.ts:339-340 documents that parameter as "the
cooperative tool-call budget (ms) attached as the tool's ToolDefinition.timeoutMs for
@deepseek-ai/dsh-tool-call-timeout-policy to enforce" (web_fetch is the same shape at
fetch.ts:444-445 and :498). A budget that can only signal a tool, against a fetch() that
never reads the signal, is the whole defect. Confirmed still present on the current release line:
at f3803c96 (release(dsh): 0.2.2-alpha.2 (#7437)) the request at
packages/web/web-deepseek-api/src/transport.ts:189 receives only the caller's signal —
...signal !== undefined ? { signal } : {} — with no deadline fused in at any phase.

Reproduction

1. Point web-deepseek-api.baseURL at any endpoint that accepts the connection and never
   responds (a plain net.createServer(() => {}) is enough).
2. Run a turn that calls web_search.
3. Observe: the tool/call event is appended; no tool/result ever follows. The session shows
   as running for as long as you care to watch. Pressing Stop / agent.cancel() does not end it.

In the wild I hit the same wedge with a misconfigured endpoint: the API answered
HTTP 402 Insufficient Balance quickly, but the turn had already hung, and the leftover call
survived the whole session.

seq 22 | tool/call | web_search {"queries": [...]}
...   (nothing — 40+ minutes later, phase still turn 1, step 1, status "running")

Proposed fix

One deadline per operation, spanning every phase — credential resolution, the request, and the
response body read — fused with the caller's cancellation via the existing
@deepseek-ai/dsh-timeout library. This is the same pattern dsh-web-fetch-http already uses
for its own transport.

• New timeoutMs setting on @deepseek-ai/dsh-web-deepseek-api, default 30 000 ms,
  resolved per operation through DeepSeekWebAuth.resolveTimeoutMs, validated against Node's
  timer range.
• When the deadline fires: abort the in-flight request and settle immediately as a new
  distinct error, WEB_PROVIDER_TIMEOUT.
  • not WEB_ABORTED — nobody cancelled it;
  • not WEB_PROVIDER_ERROR — the endpoint isn't misconfigured, it was slow.
    The distinction matters because the model should retry or escalate, not loop on a "config"
    error.
• Caller cancellation still wins its race and classifies as WEB_ABORTED.
• An operation that finishes in time disarms the timer.

Minimal shape of the change in packages/web/web-deepseek-api/src/transport.ts:

export async function dispatchDeepSeekWeb<T>(options, request, signal) {
  const timeoutMs = options.resolveTimeoutMs?.()
  assertTransportTimeout(timeoutMs)
  using d = deadline(signal, timeoutMs ?? 0, 'WEB_PROVIDER_TIMEOUT')
  try {
    return await dispatchUnderDeadline(options, request, d.signal)
  } catch (error) {
    // Our deadline won: report the timeout, not a hang or a bare abort.
    const timeout = timeoutOf(d.signal, 'WEB_PROVIDER_TIMEOUT')
    if (timeout !== undefined) throw providerTimeoutError(timeout)
    throw error
  }
}

Patch

Available on a fork branch (8 files, +177/−14):

akshaytp1571/deepseek-harness → fix/web-search-hang (commit 203ae5e3)

fix(web-deepseek-api): settle stalled searches as WEB_PROVIDER_TIMEOUT instead of hanging

Changed: transport.ts, index.ts (Config + wiring), README.md / README.zh.md,
regenerated config catalog, and tests/transport.spec.ts.

Tests

Six new cases in packages/web/web-deepseek-api/tests/transport.spec.ts:

• a stalled request settles as WEB_PROVIDER_TIMEOUT instead of hanging
• the deadline's fused signal actually reaches fetch and is aborted
• a credential resolver that never settles is bounded the same way
• an invalid timeoutMs is rejected before dispatch
• caller abort still classifies as WEB_ABORTED when it wins the race
• an operation finishing in time disarms the deadline

Package suite: 132 passed. gen-config-catalog, verify-translation-pairing,
verify-md-wrap, verify-md-links, duplication — clean.

Scope

@deepseek-ai/dsh-web-search-deepseek (the alternate Anthropic-native provider) has the same
unbounded-dispatch shape. I left it out of the patch to keep the change reviewable; the same
deadline applies there verbatim if this approach looks right.

Happy to adjust the default (30 s vs. something smaller), the error code name, or move the
deadline into the seam (dsh-web) so every provider inherits it instead of each one opting in.

[argszero]

Your diagnosis is right and I measured the boundary of it. web_search is a declared tool: applyWebSearchTool attaches timeoutMs = searchTimeoutMs, default 30_000 (packages/web/tool-web/src/index.ts:27 and :60, forwarded at packages/web/tool-web/src/search.ts:362; web_fetch is the same shape at fetch.ts:496). So the cheap plugin-side answer is not "a guard that adds a budget" — the budget already exists. It is that the core policy can only tell the tool to stop, and your stalled fetch() never notices, which is exactly the sentence you wrote.

What I ran, on the installed copy rather than the source tree — @argszero/cordis-plugin-tool-deadline-guard 0.2.1, lib from tag v0.2.1, mounted over a real ToolRuntime with a tool that declares timeoutMs: 30000 and then never settles:

mount	outcome
no plugin (control)	still pending after 800 ms — nothing settles it
plugin default config (applyTo: 'undeclared', onExpiry: 'cooperative')	still pending — it deliberately leaves declared tools to the core policy
applyTo: 'all' + onExpiry: 'replace'	settles at the deadline: isError: true, info.code === 'TOOL_DEADLINE_EXCEEDED', naming the tool
same, plus perTool: { web_search: 30000 }	the per-tool budget governs (settled at 156 ms against a 150 ms perTool), so the declared 30 s can be restored
same config, a tool that settles in time	returned untouched, same object

dsh plugin --profile <profile> add github:argszero/cordis-plugin-tool-deadline-guard#v0.2.1

with

applyTo: all
onExpiry: replace
perTool: { web_search: 30000, web_fetch: 30000 }

Two honest limits. First, replace is not the default for a reason, and your "even cancelling does not unwind it" is the reason: the replacement ends the call, not the request — the abandoned fetch keeps running unobserved, the plugin says so in a warning, and a model that retries can produce duplicate work on the same endpoint. Second, this is a mitigation, not your fix. Your patch settles the fetch (deadline fused with the caller's signal inside web-deepseek-api, distinct WEB_PROVIDER_TIMEOUT so the model escalates instead of retrying a config error) and that remains the correct change; what the mount buys is that a deployment without a patched build stops losing whole turns to one stalled endpoint. Your scope note is also right that web-search-deepseek has the same unbounded shape.

One defect I found in my own package while measuring it: under applyTo: 'all' the replacement message reads "…and the tool declares no timeoutMs of its own", which is false for a declared tool — it copies the undeclared-arm wording. Cosmetic, and I will fix it in the next release of that package.

Measured against @deepseek-ai/dsh-tools 0.2.2-alpha.2; your report is on rc.2/rc.3, and I did not run the wedge end to end against web-deepseek-api — the fixture stands in for it at the same seam.

[argszero]

One correction to what I posted above, and it comes from my own mount rather than from the report.

I handed out applyTo: 'all' in the previous comment. That mode arms exactly the tools which do declare a timeoutMs — and until today the plugin then handed them the failure message written for the other arm: …and the tool declares no timeoutMs of its own. About web_search, which declares 30_000, that is false, and it sends anyone reading the log looking for a tool without a budget as the cause.

Measured on the installed artifact — a real dsh plugin add on @deepseek-ai/dsh 0.2.1-rc.3 into a clean home, one rig, a declared tool that ignores its signal, applyTo: 'all' + onExpiry: 'replace', only the plugin version differing:

v0.2.1:

tool call to "self_timed" timed out: it exceeded the 40ms deadline supplied by the tool-deadline-guard mount, and the tool declares no timeoutMs of its own

v0.2.2, same arm, same runtime:

tool call to "self_timed" timed out: it exceeded the 40ms deadline supplied by the tool-deadline-guard mount; the call was abandoned with its work still running; the tool declares a 5000ms timeoutMs of its own, which this mount overrode because applyTo is 'all'

So install the new tag:

dsh plugin --profile <profile> add "github:argszero/cordis-plugin-tool-deadline-guard#v0.2.2"

The undeclared arm keeps its sentence verbatim, because there it is a fact; applyTo's default is unchanged; and the code stays TOOL_DEADLINE_EXCEEDED, never the core policy's TOOL_TIMEOUT, so a deployment can still tell this mount's expiry from timeout-policy's.

Nothing else above changes, and both honest limits still stand: replace ends the call, not the request — the abandoned fetch() keeps running and a retry can duplicate side effects — and the real fix for the reported hang is still the one the reporter proposed: give the provider call its own deadline.

[akshaytp1571]

Thanks — your first comment sharpened the report rather than just confirming it, so I've edited the original post to lead with your point instead of mine.

Conceding it directly: this is not a missing-timeout bug. The budget exists and is declared, and the repo says so itself. packages/web/tool-web/src/search.ts:339-340 documents the parameter as "the cooperative tool-call budget (ms) attached as the tool's ToolDefinition.timeoutMs for @deepseek-ai/dsh-tool-call-timeout-policy to enforce". A budget that can only signal a tool, against a fetch() that never reads the signal, is the entire defect. My original wording ("no default timeout") invited exactly the misreading you corrected.

On your open caveat — it reproduces on the current line, not just rc.2/rc.3.

You measured against dsh-tools 0.2.2-alpha.2 but left the end-to-end wedge unrun because the report was on rc.2/rc.3. I checked f3803c96 (release(dsh): 0.2.2-alpha.2 (#7437)) directly. packages/web/web-deepseek-api/src/transport.ts:168, dispatchDeepSeekWeb:

const auth = await authHeaders(options, request, signal)   // :171
throwIfSearchAborted(signal)                               // :172
recordRequest?.(endpoint)
throwIfSearchAborted(signal)                               // :174
response = await fetch(endpoint, {
  method: 'POST',
  redirect: 'error',
  ...
  ...signal !== undefined ? { signal } : {},               // :189
})

The request receives only the caller's cancellation signal. No deadline is fused in at any phase — not credential resolution, not the request, not the body read. So a stalled endpoint still wedges the turn on alpha.2, and Stop still cannot unwind it.

Two things that make the patch smaller than it looks:

• transport.ts:346 already has an abortable() primitive, and it is already used for the credential resolvers at :330. The request path is the only unbounded one left.
• The pattern the patch proposes is not novel, it is the in-repo one. packages/web/web-fetch-http/src/provider.ts:49 already does using d = deadline(signal, this.limits.timeoutMs, 'WEB_FETCH_TIMEOUT'), and the comment at :47-48 states the design intent exactly: one signal stops both the request and the body read, and the deadline's TimeoutReason distinguishes this provider's timeout from caller or outer-deadline cancellation. web-fetch-http/package.json declares @deepseek-ai/dsh-timeout: workspace:*.

web-deepseek-api/package.json currently declares only @deepseek-ai/schemastery, so the patch needs that one workspace dependency added. Noted on the branch.

On the correction: installing #v0.2.2, not #v0.2.1. And I'd push back gently on "cosmetic" — the wrong wording sent readers hunting for a tool with no budget as the cause, when the actual cause is a tool whose budget cannot settle the call. Pointing a diagnosis at the wrong half of the problem is a real cost, and shipping the fix in your own package after publishing the wrong message is the right call.

Both of your limits stand and I'm not going to argue them away: replace ends the call, not the request, so the abandoned fetch() keeps running unobserved and a retry can duplicate side effects; and the mount is mitigation for deployments without a patched build, not the fix. Your table is the genuinely useful part of the comment — it shows the default config deliberately leaves declared tools to the core policy, which is why applyTo: all is required, and why that is a conscious trade rather than a second bug.

Same failure family, different mechanism, in case it's useful for triage: #11486 — a gateway 413 page misclassified as context overflow, routing a request-size failure into a compaction that cannot shrink the payload. Both are cases of the harness receiving a failure it cannot act on and answering with a recovery path that cannot address it.