Summary

Fixes a bug where Hermes replies fail with 400 Invalid RootId when MATTERMOST_REPLY_MODE=thread and the user sends a message from inside an existing CRT Thread.

Root Cause

gateway/platforms/mattermost.py line 272-274 used reply_to (the user's immediate message ID) as the root_id. In Mattermost CRT, when replying inside an existing Thread, root_id must point to the thread's root-level post, not a nested reply message. Using the user's own message ID — which is itself a reply — causes Mattermost to reject with 400.

The correct root_id is already available in metadata["thread_id"], set by _thread_metadata_for_source() based on post.root_id from the incoming WebSocket event.

Why top-level channel messages worked

When the user sends from the main channel (not in a Thread), their message IS a root-level post. Using reply_to as root_id is valid in that case. The bug only manifests inside existing CRT Threads.

Fix

-            # Thread support: reply_to is the root post ID.
+            # Thread support: use the thread's root_id from metadata when
+            # replying inside an existing CRT Thread. Mattermost requires
+            # root_id to point to the root-level post, not a nested reply.
+            # Fall back to reply_to for top-level channel messages (where
+            # the user's message itself is a valid thread root).
             if reply_to and self._reply_mode == "thread":
-                payload["root_id"] = reply_to
+                thread_root = (metadata or {}).get("thread_id")
+                payload["root_id"] = thread_root or reply_to

Testing

• Reproduced on Mattermost 11.7.0 (Team Edition, Docker), MATTERMOST_REPLY_MODE=thread
• Verified fix resolves all 400 errors in gateway logs
• Verified top-level channel replies continue to work (fallback to reply_to when metadata is None)

Closes #28005