✓ Automated scan: no security concerns. Mattermost threading fix.

Supersedes #12283. Related to #12063, #12096, #6617 — same Mattermost threading code path.

Are there any merger plans?

Heads-up — the original PR included three fixes; the edit_message **kwargs hunk was independently shipped by upstream 6c0c6259 (in v2026.4.23) with a stricter *, finalize: bool = False form and a parametrized regression test across all 7 non-DingTalk adapters. A prior rebase of this branch onto upstream main already silently dropped the now-redundant hunk, so the diff currently reflects only the two genuinely-needed fixes (root_id resolution from metadata["thread_id"] and per-thread session keying for top-level messages). Updating the description to match the actual diff — both remaining fixes still apply, since upstream/main:gateway/platforms/mattermost.py still has the broken behavior at lines 273-274 and 655-656.

Rebased onto current main (clean merge). Also cleaned up the commit message to accurately reflect the two fixes in the diff.

This is a small change (+19/−5) fixing two thread-handling bugs in the Mattermost platform — happy to address any feedback. Would appreciate a review when someone has a chance. 🙏

Rebased onto current main. This is a small 2-fix PR for Mattermost threading (root_id resolution + per-thread session keying). Would appreciate a review when you get a chance. cc @teknium1

Rebased/refreshed this PR onto current main and narrowed the scope to the Mattermost thread/session bugs still missing upstream.

Changes in the refreshed branch:

• Dropped the older root-id hunk that conflicted with upstream's _resolve_root_id() work.
• Preserved upstream's _resolve_root_id(reply_to) fallback for normal replies.
• Added support for metadata["thread_id"] as the authoritative Mattermost thread root for outbound deliveries where reply_to is absent or points at a reply.
• In thread reply mode, top-level Mattermost posts now use their own post id as source.thread_id, so unrelated top-level channel threads do not share one Hermes session.
• Added focused tests for metadata thread roots and top-level thread session isolation.

Validation:

• PYTHONPATH=$PWD /Users/admin/.hermes/hermes-agent/venv/bin/python -m pytest tests/gateway/test_mattermost.py -q -o addopts=
• Result: 46 passed

I also tried the broader tests/gateway/ suite locally, but that run exhausted the macOS open-file limit in unrelated async/voice/webhook tests. The focused Mattermost suite passes cleanly.

Refreshed this PR onto current main (72ff3e909). The branch is still a single focused Mattermost threading/session commit.

Validation from the refreshed branch:

• uv run --with pytest==9.0.2 --with pytest-asyncio==1.3.0 --with pytest-timeout==2.4.0 --with aiohttp==3.13.2 pytest tests/gateway/test_mattermost.py -q -o addopts=
  • 46 passed
• python3 -m py_compile gateway/platforms/mattermost.py tests/gateway/test_mattermost.py
• git diff --check origin/main..HEAD

Independent confirmation from a real deployment

Just hit this bug on a self-hosted Mattermost install (LXC running Hermes off main at bc3f1f4, single-user EA setup) and can confirm this patch fixes it.

Repro before the patch (reply_mode=thread)

User posts top-level in ~hermes-home: bot replies, creating a thread. User replies inside that thread with a follow-up that requires context from turn 1 ("what was the number I asked you to remember?"). Bot loses context — runs session_search, finds nothing, replies "I don't know what you're asking about."

Inspection of ~/.hermes/sessions/sessions.json showed two distinct sessions for the same user in the same channel:

agent:main:mattermost:group:<channel>:7srqno17s7g5tg5fj6czzsc9ir
  origin.thread_id = null
  (top-level post — keyed by user_id because thread_id was None)

agent:main:mattermost:group:<channel>:55cwfjrtc7f13mhq7ca9z3uyqa
  origin.thread_id = "55cwfjrtc7f13mhq7ca9z3uyqa"
  (thread reply — keyed by Mattermost root_id)

Same user, same channel, but the second turn lands in a fresh session and the conversation is split. This is exactly the failure mode described in #18279.

Day-one workaround was MATTERMOST_REPLY_MODE=off (flat inline replies) — functional, but the thread experience is part of the point of using Mattermost.

After applying this PR

Patched gateway/platforms/mattermost.py with git apply against the diff in this PR, flipped MATTERMOST_REPLY_MODE back to thread, restarted the systemd gateway. Re-ran the same repro. Bot answered correctly with full context.

New sessions.json after the patched turn shows a single session, keyed by the top-level post id:

agent:main:mattermost:group:<channel>:nrgh4e8xwpd8indhf9811e591e
  origin.thread_id = "nrgh4e8xwpd8indhf9811e591e"
  (both top-level and thread reply share this session — keyed by post.id per the new branch in _handle_ws_event)

That matches the intent of the change exactly — thread_id = post.get("id") on top-level posts in thread mode means both turns share the session, and the Slack-style consistency note in the PR description rings true.

Test coverage

The three new tests in this PR cover the exact failure mode I hit:

• test_top_level_post_in_thread_mode_uses_post_id_as_thread_id — top-level post side
• test_send_thread_prefers_metadata_thread_id_over_reply_to — outbound side
• test_send_thread_uses_metadata_thread_id_when_no_reply_to — covers the "cron post into a channel without an inbound reply_to" case (which would have bitten me on the scheduled-summary feature next)

Carrying this locally

For the record — vendored the diff as a local hot-fix on my install until this merges, and documented the carry / drop process in my repo's hermes-agent docs so it doesn't get stuck applied after upstream lands.

Happy to provide more traces / sessions.json fragments if useful. +1 to merging this — it's the smallest diff that fixes the bug, the tests directly cover the failure mode, and it's been validated on a real (if small) deployment.