fix(mattermost): prevent DM replies from creating threads

[vincentkoc]

Summary

• Repair and validate the narrow Mattermost DM reply-root fix from fix(mattermost): prevent DM replies from threading via resolveMattermostReplyRootId #60115.
• Direct-message replies should not send a Mattermost root_id, while non-DM thread replies must keep using the correct thread root.
• Keep the patch scoped to monitor routing and focused tests.

Credit

This carries forward the useful fix path from @jwchmodx in #60115, with related context from #59758, #59981, #59791, #55186, and #57565.

Validation

• pnpm -s vitest run extensions/mattermost/src/mattermost/monitor.test.ts
• pnpm check:changed
• Codex /review must pass cleanly before merge.

ProjectClownfish replacement details:

• Cluster: ghcrawl-166016-agentic-merge
• Source PRs: fix(mattermost): prevent DM replies from threading via resolveMattermostReplyRootId #60115
• Credit: Credit @jwchmodx for the narrow fix(mattermost): prevent DM replies from threading via resolveMattermostReplyRootId #60115 fix path: fix(mattermost): prevent DM replies from threading via resolveMattermostReplyRootId #60115.; Mention related prior reports/attempts from Mattermost DM replies go to new Thread instead of main channel #59758, [Bug]:Mattermost: DM replies thread despite replyToMode "off" (docs say DMs stay non-threaded) #59981, fix(mattermost): prioritize threadRootId over kind===direct for DM thread replies [fixes #59758] #59791, fix(mattermost): restore threadRootId priority in thread replies #55186, and fix(mattermost): route thread replies correctly when replyToMode is off #57565 in the PR body without treating those broader branches as merged.
• Validation: pnpm -s vitest run extensions/mattermost/src/mattermost/monitor.test.ts; pnpm check:changed
• Repair fallback: validation command failed (pnpm check:changed): undefined ERR_PNPM_RECURSIVE_EXEC_FIRST_FAIL Command "check:changed" not found Did you mean "pnpm test:changed"?

[greptile-apps]

Greptile Summary

This PR suppresses root_id on Mattermost direct-message replies by adding an optional kind parameter to resolveMattermostReplyRootId and short-circuiting to undefined when kind === "direct". All three production call sites are updated to forward kind, and new tests cover both the DM-without-root and DM-with-existing-thread cases.

Confidence Score: 4/5

Safe to merge; the fix is narrow and well-tested with one minor inconsistency in the draft-preview helper that does not reintroduce the original bug.

Only P2 findings present. The fix is correct at all three delivery call sites. The sole concern is canFinalizeMattermostPreviewInPlace not forwarding kind, which means the DM guard is bypassed in the draft-preview finalization decision — but neither branch of that decision reintroduces the root_id threading bug.

extensions/mattermost/src/mattermost/monitor.ts — specifically canFinalizeMattermostPreviewInPlace around line 253.

Comments Outside Diff (1)

1. extensions/mattermost/src/mattermost/monitor.ts, line 253-258 (link)

   canFinalizeMattermostPreviewInPlace doesn't receive kind

   canFinalizeMattermostPreviewInPlace calls resolveMattermostReplyRootId internally without forwarding kind, so the DM guard introduced by this PR is bypassed here. For a DM conversation using the draft-preview streaming path, resolveMattermostReplyRootId will return the threadRootId/replyToId rather than undefined, potentially causing the function to return true (in-place edit) when it should return false (deliver normally). The in-place edit itself doesn't write root_id, so the core bug isn't reintroduced, but the preview finalization decision is inconsistent with the rest of the fix.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: extensions/mattermost/src/mattermost/monitor.ts
   Line: 253-258
   
   Comment:
   **`canFinalizeMattermostPreviewInPlace` doesn't receive `kind`**
   
   `canFinalizeMattermostPreviewInPlace` calls `resolveMattermostReplyRootId` internally without forwarding `kind`, so the DM guard introduced by this PR is bypassed here. For a DM conversation using the draft-preview streaming path, `resolveMattermostReplyRootId` will return the `threadRootId`/`replyToId` rather than `undefined`, potentially causing the function to return `true` (in-place edit) when it should return `false` (deliver normally). The in-place edit itself doesn't write `root_id`, so the core bug isn't reintroduced, but the preview finalization decision is inconsistent with the rest of the fix.
   
   How can I resolve this? If you propose a fix, please make it concise.

Prompt To Fix All With AI

This is a comment left during a code review.
Path: extensions/mattermost/src/mattermost/monitor.ts
Line: 253-258

Comment:
**`canFinalizeMattermostPreviewInPlace` doesn't receive `kind`**

`canFinalizeMattermostPreviewInPlace` calls `resolveMattermostReplyRootId` internally without forwarding `kind`, so the DM guard introduced by this PR is bypassed here. For a DM conversation using the draft-preview streaming path, `resolveMattermostReplyRootId` will return the `threadRootId`/`replyToId` rather than `undefined`, potentially causing the function to return `true` (in-place edit) when it should return `false` (deliver normally). The in-place edit itself doesn't write `root_id`, so the core bug isn't reintroduced, but the preview finalization decision is inconsistent with the rest of the fix.

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "fix(mattermost): prevent DM replies from..." | Re-trigger Greptile}

[vincentkoc]

Thanks @vincentkoc for carrying this replacement path. I am closing this as superseded by #72659 because #72659 landed the same narrow Mattermost DM reply-root fix with the repair work and green validation: direct-message replies no longer send a Mattermost root_id that creates a thread, while non-DM thread replies keep the correct thread root.

Contributor credit and source PR context were preserved in #72659. If this branch has a different reproduction path that still fails after #72659, please reply and we can reopen or split it back out.