openclaw - 💡(How to fix) Fix Feishu DM stop/停止 does not preempt active run; abort appears delayed until dispatch completes [4 comments, 2 participants]

Summary

In Feishu direct-message chats, sending stop, /stop, or 停止 during an active run does not interrupt promptly. In practice, the stop message appears to be processed only after the current dispatch finishes.

This does not match the documented out-of-band abort behavior.

Docs / expected behavior

The docs say stop should abort the active run out-of-band:

• docs/web/control-ui.md
  • Stop button calls chat.abort
  • typing /stop or standalone abort phrases like stop, stop action, stop run, stop openclaw, please stop should abort out-of-band
• docs/tools/slash-commands.md
  • /stop targets the active chat session so it can abort the current run

Core code also appears to support this:

• ABORT_TRIGGERS
• normalizeAbortTriggerText(...)
• isAbortRequestText(...)
• tryFastAbortFromMessage(...)

These exist in the built core bundle and include both English and Chinese triggers, including stop, /stop, and 停止.

Environment

• OpenClaw channel: Feishu
• Chat type: direct message
• Observed on local gateway deployment

Actual behavior

When a long-running task is active in a Feishu DM:

1. User sends a message that starts a run
2. While it is still running, user sends stop, /stop, or 停止
3. The current run is not interrupted immediately
4. The stop message seems to take effect only after the current dispatch finishes, if at all

User-facing result: Feishu behaves like "queue next message after current run", not "out-of-band abort current run".

Evidence collected

1) Feishu inbound is reaching the gateway

Gateway logs show normal inbound handling and dispatch, including patterns like:

• received message from ...
• Feishu[default] DM from ...
• dispatching to agent
• dispatch complete

So the problem does not look like "message never reached the gateway".

2) Docs + core support abort triggers

The stop phrases are documented and present in core abort logic.

3) Strong indication of serial processing in Feishu DM path

From gateway logs, the visible pattern is:

1. received message
2. dispatching to agent
3. long gap while run is active
4. dispatch complete
5. only then the next message is processed

This suggests the Feishu DM path may be effectively serializing message handling per chat/session, so the second stop message is not entering the fast-abort path while the current run is active.

Likely cause

Most likely the Feishu DM integration is not allowing stop messages to bypass normal dispatch queueing.

Possible variants:

1. Feishu inbound normalization / routing mismatch for DM path, so abort detection is not checked early enough
2. Per-chat serialized dispatch prevents the stop message from being processed until the active run finishes
3. Less likely: abort is recognized, but the active task is blocked inside a non-preemptible tool call

At the moment, the strongest evidence points to #2.

Suggested fix directions

Option A: Feishu fast-path for abort triggers

In the Feishu inbound path, before normal dispatch:

• normalize incoming DM content
• if it matches stop triggers (stop, /stop, 停止, etc.)
• resolve the active chat/session
• call the abort path directly (chat.abort / session abort)
• return early instead of enqueueing normal dispatch

Option B: ensure active-run abort checks are truly out-of-band for Feishu

If a generic fast-abort path already exists, Feishu inbound should feed it before any per-chat serialization blocks the message.

Why this matters

This is a safety / control-path issue. Users expect stop to interrupt an unintended or overly long action immediately, especially in chat-based control surfaces.

If helpful

I can provide sanitized log snippets / timestamps from the local gateway logs showing the received message -> dispatching -> dispatch complete -> next message only after completion pattern.