fix(mattermost): restore threadRootId priority in resolveMattermostEffectiveReplyToId

Jack (OpenClaw) · Jack (OpenClaw) · commit aeec08080c4a · 2026-03-26T13:10:14.000Z
Commit aaba1ae ("honor replyToMode off for threaded messages") added a replyToMode !== "off" guard to the threadRootId branch in resolveMattermostEffectiveReplyToId(). This conflates two concerns: 1. Session routing (should DM threads fork their own session?) 2. Reply delivery (should the bot reply inside the existing thread?) replyToMode controls (1), but the guard also kills (2): when replyToMode is "off" (the default for DMs), effectiveReplyToId becomes undefined, so all downstream call sites (typing indicators, reply delivery via resolveMattermostReplyRootId) lose the thread root. The bot then either posts to the main channel or gets a 400 Invalid RootId error. Fix: remove the replyToMode guard so threadRootId always flows through. replyToMode still controls session forking via resolveMattermostThreadSessionContext. Fixes #30977
diff --git a/extensions/mattermost/src/mattermost/monitor.ts b/extensions/mattermost/src/mattermost/monitor.ts
@@ -175,7 +175,7 @@ export function resolveMattermostEffectiveReplyToId(params: {
   threadRootId?: string | null;
 }): string | undefined {
   const threadRootId = params.threadRootId?.trim();
-  if (threadRootId && params.replyToMode !== "off") {
+  if (threadRootId) {
     return threadRootId;
   }
   if (params.kind === "direct") {

Original file line number	Diff line number	Diff line change
`@@ -175,7 +175,7 @@ export function resolveMattermostEffectiveReplyToId(params: {`
`175`	`175`	`threadRootId?: string \| null;`
`176`	`176`	`}): string \| undefined {`
`177`	`177`	`const threadRootId = params.threadRootId?.trim();`
`178`		`- if (threadRootId && params.replyToMode !== "off") {`
	`178`	`+ if (threadRootId) {`
`179`	`179`	`return threadRootId;`
`180`	`180`	`}`
`181`	`181`	`if (params.kind === "direct") {`