`openclaw_task_status` reports "running" long after Gateway completes task — architectural issue with status tracking

[xinleiz]

Problem

When using openclaw_chat_async to submit a task and then polling openclaw_task_status, the status remains "running" for 10+ minutes even though the OpenClaw Gateway dashboard shows the task completed in ~1-2 minutes. Eventually the status does update to "completed", but the delay makes async task tracking unreliable.

Root Cause (from source code analysis)

After reading the source code, I found that openclaw_task_status never queries the Gateway for task status. It only reads from an in-memory Map<string, Task> in TaskManager (src/mcp/tasks/manager.ts). The task status is purely derived from the lifecycle of the local HTTP request to /v1/chat/completions:

1. pending → task is in the local queue
2. running → HTTP POST sent, await-ing the response in processTask() (src/mcp/tools/tasks.ts)
3. completed → HTTP response body fully received

The problem is that the Gateway may complete the internal task (visible on its dashboard) well before the /v1/chat/completions HTTP response is sent back. This creates a blind spot where the MCP server has no way to detect that the task is already done.

Additionally, the task processor is single-threaded and sequential — only one task runs at a time, and subsequent tasks are blocked until the current one's full HTTP roundtrip completes.

Suggested Improvements

1. Poll Gateway task status independently: Instead of relying solely on the blocking HTTP response, add a mechanism to periodically check the Gateway's internal task status (if it exposes such an endpoint) and update the local TaskManager accordingly.

2. Use streaming: Switch client.chat() from non-streaming to SSE streaming (stream: true) so partial progress can be detected and the response arrives incrementally.

3. Add concurrency: Replace the single-worker sequential loop with a configurable concurrency pool to process multiple tasks in parallel.

4. Make timeout configurable: The hardcoded DEFAULT_TIMEOUT_MS = 120_000 in client.ts should be configurable via environment variable or config.

Environment

• OpenClaw Gateway: v2026.5.12, running locally on 127.0.0.1:18789
• openclaw-mcp: latest (installed via npx)
• Client: Claude Desktop (Cowork mode)

Reproduction Steps

1. Configure openclaw-mcp with a local OpenClaw Gateway
2. Send a complex task via openclaw_chat_async (e.g., "summarize today's tech news" which requires web search and takes ~1-2 min on Gateway)
3. Poll openclaw_task_status every few seconds
4. Observe that status stays "running" for 10+ minutes
5. Check Gateway dashboard — task shows as completed within 1-2 minutes

[freema]

Thanks for digging into the source — your architectural claim is correct: openclaw_task_status only reads from the in-memory TaskManager, and the running → completed transition happens purely when the local /v1/chat/completions HTTP roundtrip ends. The bridge doesn't poll the gateway, and the gateway only exposes the OpenAI-compatible /v1/chat/completions blocking endpoint — there's no separate task-status API to poll against, so suggestion #1 isn't actionable on our side.

One correction: OPENCLAW_TIMEOUT_MS already makes the timeout configurable (see src/cli.ts — defaults to 120000, can be overridden via env var or --timeout, and OPENCLAW_INSTANCES supports a per-instance timeout field too).

The reported symptom (running for 10+ minutes) doesn't quite fit the default behavior — with a 120 s timeout, the request should abort after 2 min and the task should flip to failed, not keep showing running. To narrow this down, could you share:

1. Your OPENCLAW_TIMEOUT_MS value (or --timeout flag, or per-instance timeout).
2. Debug logs (DEBUG=true) from one stuck task — full lifecycle from openclaw_chat_async queue to whatever final state it reaches.
3. Gateway-side timing for the same task (when the dashboard shows it completed vs. when the bridge actually flips to completed).

That'll tell us whether the bridge is genuinely blocked on an HTTP response that the gateway is slow to send, or whether there's a cleanup bug between the response arriving and the status update.

On the other suggestions: SSE streaming and a concurrency pool are both reasonable improvements but separate concerns from the status-reporting blind spot — happy to track them as their own enhancement issues if you'd like to break them out.