[Bug] Client Cordis inspect query hangs Pending forever — no timeout, error answers discarded

[YunlongL-byte]

Bug report: Client Cordis inspect query hangs "Pending" forever

Component: @deepseek-ai/dsh-cordis-host-runner (packages/extensions/cordis-host-runner)
Version observed: 0.1.1-rc.2
Reporter environment: macOS, dsh web GUI

Summary

A cordis_inspect_query tool call with platform: "client" stays Pending forever (observed > 30 min) when no browser page can answer it validly. The host-side pending entry is never settled: error answers from the page are silently discarded, and there is no timeout.

Reproduction

1. In a session, have the model call:
   cordis_inspect_query with {platform: "client", provider: "Service", method: "listService", input: {service: "agentPresets"}}
   (agentPresets is a Host-side service; the Client catalog has no such entry.)
2. The browser page answers with {ok: false, reason: "provider-error", message: 'no catalogued Service named "agentPresets"'}.
3. The host CordisInspectRegistryService.resolveClientQuery() hits:

   if (!resolution.ok) return { accepted: false };

   → the pending entry is left in the pending map and the query Promise is never settled.
4. The tool call stays "Pending" until the user manually cancels it. Nothing times out.

Root cause

In lib/index.js of dsh-cordis-host-runner:

• resolveClientQuery() discards any ok: false resolution and keeps the pending entry alive, waiting for a "first valid page response" that can never come (every connected page answers the same way; the client's inspect registry already marked the request answered).
• queryClient() has no timeout and no terminal condition other than a page answering ok: true or the tool-call aborting.

Net effect: any client inspect query that cannot be answered validly (wrong platform, unknown provider/service, or simply no page connected at the moment) hangs the model turn forever instead of failing fast with the concrete reason.

Suggested fix

1. In resolveClientQuery(), when a page answers with ok: false, remember the first refusal on the pending entry (pending.firstRefusal) but keep waiting (so a different page could still answer validly).
2. In queryClient(), arm a timeout (e.g. 30 s) that settles the pending query with the remembered first refusal (or a timeout error when no page answered at all), and clear the timer on settle/abort.

This preserves the multi-page "first valid answer wins" behavior while guaranteeing a bounded wait with a diagnostic error. A patch implementing exactly this has been applied and behavior-verified locally (5 scenarios: refusal+timeout surfaces the refusal; refusal then valid answer → valid wins; no page → timeout error; cancel → cancelled; fast valid answer unaffected).

Impact

Any agent session that issues a client-platform inspect query for a host-only service (or when no page is open) can be permanently wedged. The attached session trace shows the same call retried twice (turn 2 and turn 3) with zero results.

[cningan]

Independent confirmation, plus version status — the bug is still present in 0.1.5-rc.2.

Environment: dsh 0.1.5-rc.1 (Windows 10 x64, Node v24.15.0, local web GUI), and I compared the published 0.1.5-rc.2 tarballs byte-for-byte.

Measured behaviour (same shape as the report above):

• Control on the Host platform: cordis_inspect_query {platform:"host", provider:"Service", method:"listService", input:{service:"settingsScope"}} → returns in < 1 s with no catalogued Service named "settingsScope".
• Same name on the Client platform (provider:"Service", method:"listService") → never returns. Measured ≈245 s in one session before I cancelled; a separate recorded session only ended at ≈302 s because the user cancelled it. Two independent agent sessions reproduced identically.

Three additional code observations (paths relative to node_modules/@deepseek-ai/):

1. dsh-cordis-host-runner/lib/index.js:850 contains if (!resolution.ok) throw … which is unreachable — :799 already returned. That reads like the author intended a failure answer to terminate the wait; the terminal handling was simply dropped.
2. pending.delete appears exactly twice in the file: :808 (success) and :837 (abort). There is no expiry, no "all connected clients answered" aggregation, and no cleanup when a page disconnects — so the host's client manifest goes stale after any page reload (syncClientManifest has only page-driven call sites).
3. The tool's own description (dsh-tool-cordis/lib/index.js:9132) states: "A Client query waits for the first valid page response and remains pending until a page answers or the Tool is cancelled." A page did answer here (dsh-cordis-client-runner/lib/client.js:1041-1079 sends {ok:false, reason:"provider-missing"|"method-missing"|"provider-error", message}), so the documented contract is violated, not just under-specified.

Why it is reachable in normal use (worth stating in the fix rationale): queryClient:814-815 does fail fast when the provider is absent from the host mirror, so a bogus provider name is not the trigger. The hang needs a provider that is in the mirror but that no connected page can serve — which happens as soon as a page reloads or closes, because the mirror is never cleared. Zero connected clients are equally silent (dsh-api-gateway/lib/index.js:628 iterates an empty set). And there is no backstop: the tool never declares timeoutMs, and dsh-tool-call-timeout-policy is opt-in only.

Version status: dsh-cordis-host-runner, dsh-cordis-client-runner and dsh-api-gateway at 0.1.5-rc.2 are byte-identical to 0.1.5-rc.1 (SHA-256 over every file: 24/24, 18/18, 29/29 — only package.json differs), so the behaviour is unchanged in the newest published build. Note 0.1.5-rc.2 is only reachable via the next dist-tag; dsh's latest still points to 0.1.5-rc.1.

Happy to test a candidate build if one becomes available, and I can share the sanitized repro/session notes if useful.