fix(slack): track assistant typing per-thread to unstick concurrent chats

[briandevans]

Summary

• A single Slack channel/DM can host multiple Assistant threads at once. The typing-indicator tracker was keyed only by chat_id, so a second concurrent send_typing overwrote the first thread's thread_ts and the earlier thread was left stuck in "is thinking…" forever.
• This PR extends the per-chat tracker to a per-thread set, routes stop_typing by metadata["thread_ts"] when present, and also clears the indicator when send() fails.

The bug

gateway/platforms/slack.py tracked the active Assistant status thread per chat:

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

send_typing(chat_id, metadata) wrote self._active_status_threads[chat_id] = thread_ts, so two overlapping Assistant requests in the same Slack channel/DM collided. stop_typing(chat_id, ...) then popped the dict and cleared whichever thread_ts was last written — usually the wrong (newer) one. The result: the older Slack Assistant thread stayed in is thinking… indefinitely even though Hermes had already replied to it. Reported in #24117.

A related failure path: the send() exception branch did not clear the typing indicator at all, so a Slack post error left the user staring at is thinking… until the gateway restarted.

The fix

• _active_status_threads: Dict[str, set[str]] — track each active thread.
• send_typing adds thread_ts to the chat's set (bounded at 128 active threads per chat as a defensive guard against missed clears).
• stop_typing(chat_id, metadata={"thread_ts": ts}) clears exactly that thread. Called without metadata, it clears every tracked thread for the chat (preserves the legacy base.py wiring that calls stop_typing(chat_id) without thread context).
• send() finalize now passes its own thread_ts to stop_typing so it only clears its own thread among concurrent ones.
• send() exception path now also clears the thread's status, so a failed Slack post doesn't leave the user stuck on is thinking….
• edit_message(finalize=True) is unchanged — it has no thread context to target, and clearing every tracked thread for the chat matches the existing behavior.

Test plan

• Focused regression tests: tests/gateway/test_slack.py::TestSendTyping — 16/16 passing including five new tests covering concurrent threads, per-thread stop_typing routing, the legacy clear-all path, send-failure clearing, and the per-chat bound.
• Adjacent suite: full tests/gateway/test_slack.py (186 passed), plus test_slack_approval_buttons.py / test_slack_channel_skills.py / test_slack_mention.py (89 passed).
• Ruff: ruff check gateway/platforms/slack.py tests/gateway/test_slack.py clean.

Regression guard — the two new tests fail against current main:

• test_send_typing_tracks_multiple_concurrent_threads — asserts both thread_a and thread_b are tracked after two send_typing calls in the same chat. With the old Dict[str, str] shape, the second overwrites the first.
• test_send_clears_only_targeted_thread_among_concurrent — asserts that send(metadata={"thread_id": "thread_a"}) clears only thread_a and leaves thread_b tracked. The old code popped the dict and cleared whichever single thread happened to be stored.

Related

• Fixes Slack Assistant thread can stay stuck in 'is thinking...' after response is sent #24117
• Builds on fix(gateway/slack): batch salvage — reserved commands, session isolation, delivery fixes #18553 (April 22 — single-thread lifecycle). That fix is correct for one Assistant thread per chat; this PR extends the invariant to concurrent threads.
• The edit_message path is intentionally left clearing-all-by-chat because it has no per-message thread context. Happy to widen if a maintainer prefers carrying thread_ts through edit_message's call sites.

[Copilot]

Pull request overview

Fixes a Slack adapter lifecycle bug where concurrent Assistant threads in the same channel/DM could overwrite each other’s tracked typing/status thread, leaving older threads stuck showing “is thinking…”. The change updates tracking to be per-(chat, thread) and ensures status cleanup happens for the correct thread, including on send failures.

Changes:

• Change _active_status_threads from a per-chat single thread_ts to a per-chat set[thread_ts] to support concurrent Assistant threads.
• Route stop_typing() to clear a specific thread when metadata["thread_id"/"thread_ts"] is provided; otherwise clear all tracked threads for the chat (legacy behavior).
• Update send() to clear typing for its own resolved thread_ts, and attempt cleanup on exceptions; add regression tests covering concurrency, targeted clearing, failure cleanup, and per-chat bounding.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
gateway/platforms/slack.py	Implements per-thread status tracking/clearing and adds best-effort cleanup on send failure.
tests/gateway/test_slack.py	Updates existing tests for the new tracking shape and adds focused regression coverage for concurrent-thread scenarios and bounds.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[briandevans]

@copilot Addressed in c604e8c — stop_typing now discards the tracked thread only after the assistant.threads.setStatus clear succeeds. On a transient API failure the thread stays in _active_status_threads so a later stop_typing (next finalize, or a no-metadata bulk clear) can retry the clear; on permanent failures (e.g. missing assistant:write scope) the exception is still swallowed.

Updated tests:

• test_stop_typing_handles_api_error_gracefully now asserts the thread stays tracked on failure (was asserting it was popped).
• Added test_stop_typing_partial_failure_keeps_failed_thread_tracked for the mixed success/failure case: succeeding threads are discarded, failing ones remain tracked.

[briandevans]

CI audit — all 3 failing checks on this PR are pre-existing baselines on clean origin/main (32abe742f). Zero failures are in touched code (gateway/platforms/slack.py, tests/gateway/test_slack.py).

Job	Symptom	Root cause on main
test / e2e (Tests workflow)	uv pip install -e .[all,dev] fails: Because there are no versions of mistralai and hermes-agent[all]==0.13.0 depends on mistralai>=2.3.0,<3	pyproject.toml on main pins mistralai>=2.3.0,<3 but no satisfying version is currently resolvable on PyPI. Same failure on main's own scheduled run 25713449972.
Windows footguns (blocking) (Lint workflow)	tools/process_registry.py:588: [bare os.killpg] / [bare signal.SIGKILL]	Pre-existing on main: os.killpg(os.getpgid(proc.pid), signal.SIGKILL) at tools/process_registry.py:588. Same failure on main's own scheduled run 25713449992.

Happy to address the Copilot finding (already fixed in c604e8c3c) or any review comments — just flagging that the red CI badge here isn't from this PR.