hermes - 💡(How to fix) Fix Slack Assistant thread can stay stuck in 'is thinking...' after response is sent

Bug Description

Slack Assistant threads can remain stuck showing is thinking... after Hermes has already finished generating and sent the final reply.

This appears to be a Slack adapter lifecycle bug around assistant.threads.setStatus, not a model/gateway hang. Gateway logs show the response has completed and Hermes has sent the message, but the Slack Assistant status indicator is not reliably cleared for the affected thread.

Evidence / Observed Behavior

On a Slack gateway session:

response ready: platform=slack chat=<channel-or-dm> time=... api_calls=... response=... chars
[Slack] Sending response (...) to <channel-or-dm>

The final assistant message is visible in Slack, but the thread can continue to show the Assistant UI status as is thinking....

Clearing the status manually with Slack's assistant.threads.setStatus using an empty status string clears the stale indicator, which points to status lifecycle cleanup rather than inference still running.

Likely Root Cause

The Slack adapter tracks active Assistant statuses by chat_id only:

self._active_status_threads: Dict[str, str] = {}

But a Slack channel/DM can have multiple Assistant threads active concurrently. If two requests in the same chat_id overlap, a later request can overwrite the earlier thread_ts. When the earlier run finishes, stop_typing() may clear the wrong/newer thread or have already lost the older thread_ts, leaving the older Slack Assistant thread stuck in is thinking....

There is also a related failure path: if final send fails, the adapter should still attempt to clear the Assistant status for the relevant thread, otherwise Slack UI can be left stale.

Expected Behavior

After Hermes finishes and posts the final Slack reply, the corresponding Slack Assistant thread status should always be cleared.

This should hold for:

• Multiple concurrent Slack Assistant threads in the same DM/channel
• Threaded channel conversations
• DM conversations using Assistant threads
• Send failure / exception paths

Actual Behavior

Slack may keep showing is thinking... for a thread even after:

• Hermes logged response ready
• Hermes logged [Slack] Sending response
• The final reply appeared in Slack
• Gateway remains healthy and continues serving other messages

Proposed Fix

Track active Assistant statuses per thread, not just per chat:

self._active_status_threads: Dict[str, set[str]] = {}

Then:

1. In send_typing(chat_id, metadata), add the concrete thread_ts to the set for that chat.
2. In stop_typing(chat_id, metadata), prefer metadata["thread_ts"] / metadata["thread_id"] and clear exactly that status with:

   assistant.threads.setStatus(channel_id=chat_id, thread_ts=thread_ts, status="")

3. If no metadata is available, clear all tracked thread statuses for that chat as a fallback.
4. After final chat.postMessage, call stop_typing(chat_id, {"thread_ts": thread_ts}) rather than clearing by chat only.
5. In the send() exception path, call stop_typing(chat_id, metadata) before returning failure.

Environment

• Hermes Agent: v0.13.0 (2026.5.7)
• Platform: Slack gateway / Slack Assistant
• OS observed: macOS 26.4
• Python: 3.11.14

Related Searches

I searched open issues for Slack Assistant thinking status, slack thinking, assistant.threads.setStatus, and assistant status slack. I found Slack-related issues, but none that appear to cover this exact stale Assistant is thinking... lifecycle bug.