Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Mattermost message tool handler ignores threadId, filePath/path, and mediaLocalRoots [1 pull requests, 1 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#67784•Fetched 2026-04-17 08:29:24
View on GitHub
Comments
0
Participants
1
Timeline
2
Reactions
0
Author
reymarquesreymarques
Participants
reymarquesreymarques
Timeline (top)
cross-referenced ×1referenced ×1

Fix Action

Workaround

Local patch to channel-plugin-runtime-*.js:

  • Add mediaLocalRoots to the handleAction destructured params
  • Extract threadId from params.threadId
  • Fall through params.media → params.filePath → params.path for mediaUrl
  • Pass threadId and mediaLocalRoots to sendMessageMattermost

PR fix notes

PR #67796: fix(mattermost): support filePath and path as mediaUrl fallbacks in handleAction

Description (problem / solution / changelog)

Summary

The Mattermost handleAction only checked params.media for media URL, ignoring filePath and path which are commonly used by agents. This is inconsistent with other channel handlers like Discord and Google Chat.

Problem

When an agent uses the message tool with filePath or path instead of media:

  • Discord handler: supports media → path → filePath fallback
  • Google Chat handler: supports media → filePath → path fallback
  • Mattermost handler: only checks media → file upload fails silently

Fix

Add fallback chain for media URL resolution:

  1. params.media
  2. params.filePath
  3. params.path

Related

This is a partial fix for #67784. The other parts (threadId and mediaLocalRoots) are already addressed by:

  • PR #52120 (thread context inheritance)
  • PR #58439 (mediaLocalRoots forwarding)

Test Plan

  • Existing unit tests pass
  • Lint passes

Closes openclaw#67784 (filePath/path fallback only)

Changed files

  • extensions/mattermost/src/channel.ts (modified, +7/-1)
RAW_BUFFERClick to expand / collapse

Bug

The Mattermost handleAction in channel-plugin-runtime (the message tool's action: send path) drops several parameters that other channel handlers (Discord, Slack) already support:

  1. threadId — never extracted from params, so file sends always land in the main channel instead of the thread
  2. filePath / path — not checked as fallback sources for mediaUrl, so local file uploads fail silently (agent says "attached" but only posts text)
  3. mediaLocalRoots — not destructured from the handler context and not passed to sendMessageMattermost, so even if a local path were provided, the media loader can't resolve it

Expected behavior

When an agent calls the message tool with action: send, channel: mattermost, filePath: "/path/to/file.xlsx", and threadId: "<root_post_id>", the file should be uploaded to the correct Mattermost thread.

Actual behavior

  • threadId is ignored → post goes to channel root
  • filePath/path are ignored → no file upload, just text
  • mediaLocalRoots unavailable → even media with a local path can't resolve

Workaround

Local patch to channel-plugin-runtime-*.js:

  • Add mediaLocalRoots to the handleAction destructured params
  • Extract threadId from params.threadId
  • Fall through params.media → params.filePath → params.path for mediaUrl
  • Pass threadId and mediaLocalRoots to sendMessageMattermost

Environment

  • OpenClaw 2026.4.10
  • macOS, Mattermost channel plugin
  • Affects all agents using the message tool for Mattermost file delivery

extent analysis

TL;DR

Apply a local patch to channel-plugin-runtime-*.js to fix the Mattermost handleAction function and correctly handle threadId, filePath, and mediaLocalRoots parameters.

Guidance

  • Extract threadId from params.threadId to ensure file sends land in the correct thread.
  • Implement a fallback check for mediaUrl using params.filePath and params.path to support local file uploads.
  • Destructure mediaLocalRoots from the handler context and pass it to sendMessageMattermost to enable media loading from local paths.
  • Verify the fix by testing file uploads with the action: send path and checking that files are uploaded to the correct thread.

Example

const { threadId, mediaLocalRoots } = params;
const mediaUrl = params.media || params.filePath || params.path;
// Pass threadId and mediaLocalRoots to sendMessageMattermost
sendMessageMattermost({ threadId, mediaUrl, mediaLocalRoots });

Notes

This fix assumes that the sendMessageMattermost function can handle the additional parameters. If not, further modifications may be necessary.

Recommendation

Apply the workaround by patching the channel-plugin-runtime-*.js file, as the issue affects all agents using the message tool for Mattermost file delivery and there is no clear indication of a fixed version available.

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

When an agent calls the message tool with action: send, channel: mattermost, filePath: "/path/to/file.xlsx", and threadId: "<root_post_id>", the file should be uploaded to the correct Mattermost thread.

#response parsing#generation error#database connection#vector store#embedding generation

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 Mattermost message tool handler ignores threadId, filePath/path, and mediaLocalRoots [1 pull requests, 1 participants]