fix(slack): avoid assistant status on synthetic top-level threads

When reply_in_thread=false, top-level channel events carry their own
message ts as metadata.thread_id for session keying. Calling
assistant.threads.setStatus on that ts activated a Slack assistant
thread ('is thinking...') before the actual response was sent, and the
flat reply then never cleared it.

send_typing now routes through the same _resolve_thread_ts synthetic-
thread guard as message sending, and the gateway threads message_id
through progress/status metadata so the adapter can distinguish real
threads from synthetic top-level session keys.

Reapplied from #18859-sibling PR #17184 by @dorukardahan (both commits:
fix + progress-metadata test) onto current main via 3-way apply — the
original patched gateway/platforms/slack.py, moved to
plugins/platforms/slack/adapter.py in the plugin migration.
This commit is contained in:
Doruk Ardahan 2026-07-23 07:56:10 -07:00 committed by Teknium
parent 62747aa584
commit e40a38aa29
4 changed files with 66 additions and 5 deletions

View file

@ -2536,7 +2536,15 @@ class SlackAdapter(BasePlatformAdapter):
thread_ts = None
if metadata:
thread_ts = metadata.get("thread_id") or metadata.get("thread_ts")
# Reuse the same synthetic-thread guard as message sending. When
# reply_in_thread=false, top-level channel events carry their own
# message ts as metadata.thread_id for session keying. Calling
# assistant_threads_setStatus on that ts activates a Slack assistant
# thread before the actual response is sent.
thread_ts = self._resolve_thread_ts(
reply_to=metadata.get("message_id"),
metadata=metadata,
)
if not thread_ts:
return # Can only set status in a thread context