Bug: cordis_inspect_query (platform=client) hangs when the page returns an error resolution

[iceprosurface]

Summary

cordis_inspect_query with platform: "client" hangs indefinitely (never returns) whenever the Client page does answer the query but with an error resolution (ok: false) — e.g. an exact Service.listService query for a service name that does not exist in the client catalog. The tool call stays pending until cancelled, then surfaces the misleading error …: Client inspect query Service.listService was cancelled. Host-platform queries are unaffected (they run locally and are fast).

Environment

• dsh: 0.1.0-rc.6
• @deepseek-ai/dsh-tool-cordis: 0.1.0-rc.6
• @deepseek-ai/dsh-cordis-host-runner: 0.1.0-rc.6
• @deepseek-ai/dsh-cordis-client-runner: 0.1.0-rc.6

Steps to reproduce

1. Call cordis_inspect_list and pick a Client provider (e.g. Service).
2. Call cordis_inspect_query with platform: "client", provider: "Service", method: "listService", input: { "service": "<name not present in the client catalog>" }.
3. The page answers promptly with an error (e.g. no catalogued Service named "<name>"), but the tool call never returns — it hangs until cancelled.
4. Cancelling yields Error: Service.listService: Client inspect query Service.listService was cancelled, which incorrectly suggests the client never responded.

Root cause

In @deepseek-ai/dsh-cordis-host-runner, CordisInspectRegistryService.resolveClientQuery silently drops client error resolutions:

resolveClientQuery(agent, requestId, resolution) {
    const pending = this.pending.get(requestId);
    if (pending === undefined || pending.request.agentId !== agent.id)
        return { accepted: false };
    if (!resolution.ok)                       // <-- client error is dropped here
        return { accepted: false };
    try {
        resolution = {
            ok: true,
            data: validateOutput('Client', pending.request.provider, pending.method, resolution.data),
        };
    } catch {                                 // <-- output validation failure is dropped too
        return { accepted: false };
    }
    this.pending.delete(requestId);
    pending.settle(resolution);
    this.ctx.emit('cordis/inspect-query-resolved', { requestId });
    return { accepted: true };
}

When the client answers { ok: false, reason, message }, the host returns { accepted: false } without ever calling pending.settle(...). The promise awaited in queryClient never resolves, so the tool call blocks until the caller's signal aborts (reporting "was cancelled"). The same drop applies when the client's data fails Host-side output validation (validateOutput throws).

Suggested fix

Settle the pending query on any client answer (success, error, or invalid output), so failures are returned to the caller instead of hanging:

resolveClientQuery(agent, requestId, resolution) {
    const pending = this.pending.get(requestId);
    if (pending === undefined || pending.request.agentId !== agent.id)
        return { accepted: false };
    this.pending.delete(requestId);
    if (!resolution.ok) {
        pending.settle({
            ok: false,
            reason: resolution.reason ?? 'client-error',
            message: resolution.message ?? `Client inspect query ${pending.request.provider}.${pending.request.method} failed`,
        });
        this.ctx.emit('cordis/inspect-query-resolved', { requestId });
        return { accepted: true };
    }
    try {
        resolution = {
            ok: true,
            data: validateOutput('Client', pending.request.provider, pending.method, resolution.data),
        };
    } catch (error) {
        pending.settle({
            ok: false,
            reason: 'invalid-output',
            message: error instanceof Error ? error.message : String(error),
        });
        this.ctx.emit('cordis/inspect-query-resolved', { requestId });
        return { accepted: true };
    }
    pending.settle(resolution);
    this.ctx.emit('cordis/inspect-query-resolved', { requestId });
    return { accepted: true };
}

Notes:

• pending.delete is hoisted so every query settles at most once.
• accepted: false is only returned when the pending entry is missing or belongs to another agent (already settled/cancelled elsewhere) — previous semantics preserved.

Verification

Reproduced with the real registry class (CordisInspectRegistryService) and a mirrored client manifest:

Client answer	Before	After fix
{ ok: true, data }	settles	settles
{ ok: false, message }	hangs until cancelled ("was cancelled")	immediately rejects with the real client error
invalid output	hangs until cancelled	immediately rejects with the validation error

After the fix, the pending map no longer leaks entries.

[po-et]

Thanks for the detailed report. I reproduced this on current master and have a small patch ready.

The change keeps accepted: false for unknown, cross-agent, or late responses, but allows the first matching response to settle the pending query:

• structured Client failures are passed through;
• successful responses are validated by the Host, with validation failures surfaced through the existing provider-error.

I added regression tests for both reported failure paths, abort-after-answer, and late-answer rejection. The cordis-host-runner suite passes (93 tests), as does pnpm typecheck.

I noticed that CONTRIBUTING.md currently says external PRs are not accepted. Would the maintainers be open to a focused PR for this fix, or would you prefer the patch here in the discussion?

[xxn971205]

Still reproducible on 0.1.1-rc.2 on macOS.

I inspected a real exported session together with the currently installed Client/Host runners:

• Known-good Client queries, including Slots.listSubTree and Service.listService({ service: "slots" }), completed in 18–304 ms.
• Four calls to Service.listService({ service: "sidePanel" }) remained pending for approximately 580.5 s, 989.1 s, 133.9 s, and 434.7 s. Each returned only after user cancellation, with Service.listService: Client inspect query Service.listService was cancelled.
• sidePanel is a custom runtime Cordis service and is not present in the static Inspect Service catalog, so the Client correctly produces no catalogued Service named "sidePanel" and sends an { ok: false, reason: "provider-error" } resolution.
• The Host's resolveClientQuery still returns { accepted: false } for that matching error response without deleting or settling the pending query.
• A minimal in-process reproduction against the rc.2 Host runner confirms that after a matching { ok: false, ... } response, the pending map still contains the request.

This confirms that this case is not caused by a missing or disconnected browser page: the Client responds, but the Host drops the error resolution. The same Host implementation is present in the locally installed 0.1.0-rc.8, 0.1.1-rc.1, and 0.1.1-rc.2 versions.

The no-response timeout problem discussed in #1607 is a related safety-net gap. Both protections appear useful: settle every matching Client response first, then use a bounded timeout for genuinely unanswered Client queries.