Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]:Mattermost: DM replies thread despite replyToMode "off" (docs say DMs stay non-threaded) [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#59981•Fetched 2026-04-08 02:37:59
View on GitHub
Comments
1
Participants
2
Timeline
5
Reactions
0
Author
Stevetaiapa1967Stevetaiapa1967
Participants
GMTekAIGMTekAIStevetaiapa1967Stevetaiapa1967
Timeline (top)
labeled ×2commented ×1cross-referenced ×1referenced ×1

Mattermost DM auto-replies are sent with a non-empty root_id, creating threads in the DM channel, despite documentation stating that direct messages ignore replyToMode and stay non-threaded.

Root Cause

Mattermost DM auto-replies are sent with a non-empty root_id, creating threads in the DM channel, despite documentation stating that direct messages ignore replyToMode and stay non-threaded.

Fix Action

Fixed

PR fix notes

PR #60115: fix(mattermost): prevent DM replies from threading via resolveMattermostReplyRootId

Description (problem / solution / changelog)

Problem

Mattermost DM auto-replies were sent with a non-empty root_id, creating threads in the DM channel despite the documentation stating that direct messages ignore replyToMode and stay non-threaded.

The bug was in resolveMattermostReplyRootId: it would fall back to payload.replyToId regardless of chat kind. Even though resolveMattermostEffectiveReplyToId already correctly returns undefined for DMs (guarding session-key resolution), the delivery path could still reintroduce a thread root when a downstream payload carried a replyToId — for example, during block-streaming delivery where each block carries the inbound post ID as replyToId.

This caused all DM bot replies to appear as threads, making the main channel body appear empty to users.

Fixes #59981

Fix

Add kind: ChatType to resolveMattermostReplyRootId and hard-return undefined when kind === "direct", mirroring the guard that already existed in resolveMattermostEffectiveReplyToId.

Update all three delivery call sites to pass kind:

  1. Main inbound message replies
  2. Button-click interaction replies
  3. Model picker command replies

Tests

Added two regression tests to resolveMattermostReplyRootId:

  • DM with replyToId → undefined (was: returns replyToId, causing threading)
  • DM with both threadRootId and replyToId → undefined

All 22 Mattermost monitor tests pass.

pnpm vitest run extensions/mattermost/src/mattermost/monitor.test.ts
✓ 22 tests passed

Changed files

  • extensions/mattermost/src/mattermost/monitor.test.ts (modified, +26/-1)
  • extensions/mattermost/src/mattermost/monitor.ts (modified, +9/-0)
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Mattermost DM auto-replies are sent with a non-empty root_id, creating threads in the DM channel, despite documentation stating that direct messages ignore replyToMode and stay non-threaded.

Steps to reproduce

  1. Install @openclaw/mattermost plugin
  2. Configure with dmPolicy: "open" and replyToMode: "off"
  3. Send a DM to the bot from a Mattermost user
  4. Observe the bot's auto-reply via GET /api/v4/channels/{dm_channel_id}/posts
  5. Note that the reply post has a non-empty root_id matching the triggering post ID
  6. In the Mattermost client, the reply appears as a thread rather than in the main DM body

Expected behavior

DM replies land in the main channel body with root_id empty. Documentation explicitly states: "Direct messages ignore this setting and stay non-threaded."

Actual behavior

Bot auto-replies are sent with a non-empty root_id set to the triggering post ID, creating a thread in the DM. The main channel body appears empty to the user. Confirmed via Mattermost REST API: GET /api/v4/channels/{dm_channel_id}/posts shows root_id populated on all bot replies.

OpenClaw version

2026.4.2

Operating system

Mac OS 15.7.4

Install method

Installed via npm globally

Model

anthropic 4.6

Provider / routing chain

Claude Sonnet 4.6

Additional provider/model setup details

Plugin: @openclaw/mattermost Config: replyToMode: "off", dmPolicy: "open"

Expected: DM auto-replies land in the main channel body. Docs state "Direct messages ignore this setting and stay non-threaded."

Actual: Auto-replies are sent with a non-empty root_id, creating a thread in the DM conversation. Confirmed via Mattermost API — posts show root_id set to the triggering post ID.

The resolveMattermostReplyToMode function correctly returns "off" for direct kind, but payload.replyToId still gets passed through to root_id in the outbound post via resolveMattermostReplyRootId.

This makes DM conversations unusable as the main channel body appears empty to the user.

Logs, screenshots, and evidence

Impact and severity

unable to communicate effectively

Additional information

No response

extent analysis

TL;DR

The issue can be fixed by ensuring the root_id is empty for direct messages, which may involve modifying the resolveMattermostReplyRootId function to handle direct messages correctly.

Guidance

  • Review the resolveMattermostReplyRootId function to ensure it correctly handles direct messages and sets root_id to empty when replyToMode is "off".
  • Verify that the resolveMattermostReplyToMode function is correctly returning "off" for direct messages and that this value is being used to determine the root_id.
  • Check the Mattermost API documentation to confirm the expected behavior for direct messages and root_id.
  • Test the fix by sending a DM to the bot and verifying that the auto-reply has an empty root_id and appears in the main channel body.

Example

No code snippet is provided as the issue does not include sufficient code details.

Notes

The fix may depend on the specific implementation of the resolveMattermostReplyRootId function, which is not provided in the issue.

Recommendation

Apply a workaround by modifying the resolveMattermostReplyRootId function to correctly handle direct messages, as the root cause appears to be related to this function.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

DM replies land in the main channel body with root_id empty. Documentation explicitly states: "Direct messages ignore this setting and stay non-threaded."

#api#ssr#installation#tensor shape#request timeout

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Bug]:Mattermost: DM replies thread despite replyToMode "off" (docs say DMs stay non-threaded) [1 pull requests, 1 comments, 2 participants]