Summary

OpenResponses HTTP API generated runIds are not registered in Gateway's chatAbortControllers Map, causing chat.abort requests to be silently ignored and tasks to continue executing until completion.

Steps to reproduce

Prerequisites: OpenClaw Gateway running on localhost:18789 with a valid auth token.

Step 1: Start a long-running task via OpenResponses HTTP API:

# Create a task that takes ~30 seconds to complete
curl -X POST http://localhost:18789/v1/responses \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -H "Content-Type: application/json" \
  -H "x-openclaw-agent-id: main" \
  -d '{
    "model": "openclaw:main",
    "input": "Count from 1 to 10, waiting 3 seconds between each number. Print each number as you count."
  }'

Step 2: Capture the runId from the response (format: resp_xxx).

Step 3: Immediately attempt to abort the task:

openclaw gateway call chat.abort --params '{"runId": "resp_xxx"}'

Step 4: Observe the task output — the counting continues to completion despite the abort request.

Expected behavior

1. Immediate termination: Calling chat.abort with a valid runId from OpenResponses API should immediately terminate the associated agent task.

2. Consistent behavior: OpenResponses HTTP API and Gateway RPC WebSocket should exhibit identical abort behavior — both should register the runId in chatAbortControllers and respond to abort requests.

3. Accurate response: The chat.abort response should return:

   {
     "aborted": true,
     "runIds": ["resp_xxx"]
   }

4. Task state: The running task should stop immediately, releasing any held resources, and the agent should not continue processing remaining steps.

Actual behavior

When calling openclaw gateway call chat.abort with the runId returned by the OpenResponses API:

1. The abort request returns aborted: false with empty runIds: [], indicating no task was found to abort:

   {
     "ok": true,
     "result": {
       "aborted": false,
       "runIds": []
     }
   }

2. The task continues executing to completion despite the abort request. All steps in the agent's plan run to the end, creating files, making API calls, etc.

3. No user-visible error is returned — the abort call silently fails. The API returns a successful response ("ok": true), giving the false impression that the operation succeeded.

4. The discrepancy between API response and actual behavior creates confusion:

   • aborted: false + empty runIds suggests "nothing was running"
   • But the task is clearly still executing (observable via file creation, logs, etc.)

5. This only affects OpenResponses HTTP API — the same abort mechanism works correctly when using Gateway RPC WebSocket (chat.send), because those runId values are properly registered in the chatAbortControllers Map.

Root Cause:
The runId generated by the OpenResponses HTTP API (format: resp_xxx) is not registered in the Gateway's chatAbortControllers Map. When chat.abort is called, it searches this Map and finds no matching controller, resulting in a silent no-op.

OpenClaw version

2026.2.24

Operating system

Ubuntu 25.04

Install method

npm global

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response