Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Mattermost: bot does not see file attachments (file_ids empty in WebSocket event) [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#59576•Fetched 2026-04-08 02:43:00
View on GitHub
Comments
0
Participants
1
Timeline
3
Reactions
1
Author
alexanderkreidichalexanderkreidich
Participants
alexanderkreidichalexanderkreidich
Timeline (top)
referenced ×2cross-referenced ×1

The Mattermost plugin fails to detect file attachments on incoming messages. The bot responds as if no file was attached, even when the user clearly attached a file (XLSX, XLSM, etc.).

Root Cause

Mattermost server broadcasts the posted WebSocket event before file attachment linkage is finalized. The post object in the event arrives with file_ids: [] (empty array), so resolveMattermostMedia() finds nothing to download.

This is a known Mattermost server behavior (documented across v5.x–v9.x): file processing is asynchronous, and the WebSocket event fires before it completes. Larger files make the race more likely.

Fix Action

Fixed

PR fix notes

PR #59591: fix(mattermost): re-fetch file_ids when WebSocket event arrives with empty attachments

Description (problem / solution / changelog)

Summary

  • Problem: Mattermost server broadcasts the posted WebSocket event before file attachment linkage is finalized, so file_ids is always [] — the bot never sees attached files.
  • Why it matters: Users attach files (XLSX, images, etc.) and the bot responds saying no file was attached.
  • What changed: When file_ids is empty, re-fetch the post via REST with progressive back-off (500ms, then 1500ms) to obtain the populated array. This is the standard workaround — Mattermost has no secondary event or metadata signal for file linkage completion.

Change Type

  • Bug fix

Scope

  • Integrations

Linked Issue/PR

  • Closes #59576
  • Related #33946
  • Related #43435
  • This PR fixes a bug or regression

Root Cause / Regression History

  • Root cause: Mattermost server architecture — attachFilesToPost() runs after the WebSocket broadcast. Documented across Mattermost v5.x–v9.x; not a regression on our side.
  • Missing detection / guardrail: No re-fetch logic existed for empty file_ids.

Security Impact

  • New permissions/capabilities? No
  • Secrets/tokens handling changed? No
  • New/changed network calls? Yes — one additional GET /api/v4/posts/{id} call (up to 2 attempts) when file_ids is empty
  • Command/tool execution surface changed? No
  • Data access scope changed? No
  • If any Yes: The REST call uses the existing authenticated MattermostClient. No new credentials or endpoints. Post ID comes from the already-trusted WebSocket event payload.

Risks and Mitigations

  • Risk: Text-only messages incur ~2s overhead (500ms + 1500ms) and 2 REST calls because there is no server-side signal to distinguish "no files" from "files not yet linked" — both return file_ids: [] from REST.
    • Mitigation: Re-fetch is skipped for debounced merged posts (wrong post ID, known gap). Transient REST errors do not abort the retry loop. No Mattermost signal exists to avoid this — confirmed via API docs research.

Changed files

  • extensions/mattermost/src/mattermost/client.test.ts (modified, +15/-0)
  • extensions/mattermost/src/mattermost/client.ts (modified, +7/-0)
  • extensions/mattermost/src/mattermost/monitor-resources.test.ts (modified, +123/-22)
  • extensions/mattermost/src/mattermost/monitor-resources.ts (modified, +28/-0)
  • extensions/mattermost/src/mattermost/monitor.ts (modified, +11/-1)
RAW_BUFFERClick to expand / collapse

Summary

The Mattermost plugin fails to detect file attachments on incoming messages. The bot responds as if no file was attached, even when the user clearly attached a file (XLSX, XLSM, etc.).

Reproduction

  1. Send a message with a file attachment (e.g. 12MB XLSM) to the bot in Mattermost
  2. Bot responds saying no file is attached
<img width="1128" height="261" alt="Image" src="https://github.com/user-attachments/assets/b48bbd17-171e-4965-b6ca-a2ff4231397f" />

Note: Screenshot shows a user sending an XLSM file (12MB) and the bot responding: "It looks like the file didn't come through with your message though. Could you share it?"

Root Cause

Mattermost server broadcasts the posted WebSocket event before file attachment linkage is finalized. The post object in the event arrives with file_ids: [] (empty array), so resolveMattermostMedia() finds nothing to download.

This is a known Mattermost server behavior (documented across v5.x–v9.x): file processing is asynchronous, and the WebSocket event fires before it completes. Larger files make the race more likely.

Proposed Fix

  1. Add a fetchMattermostPost() REST helper to extensions/mattermost/src/mattermost/client.ts (GET /api/v4/posts/{post_id})
  2. In extensions/mattermost/src/mattermost/monitor.ts (~line 1264), when post.file_ids is empty/null, re-fetch the post via REST after a short delay (1-2s) to obtain the populated file_ids
  3. Pass the re-fetched file_ids to resolveMattermostMedia()

Affected Files

  • extensions/mattermost/src/mattermost/client.ts
  • extensions/mattermost/src/mattermost/monitor.ts
  • extensions/mattermost/src/mattermost/monitor-resources.ts

extent analysis

TL;DR

Implement a delay-based retry mechanism to re-fetch the post and obtain the populated file_ids after receiving the posted WebSocket event with an empty file_ids array.

Guidance

  • Verify that the Mattermost server version is within the known affected range (v5.x-v9.x) to confirm the asynchronous file processing behavior.
  • Implement the proposed fix by adding a fetchMattermostPost() REST helper and re-fetching the post with a short delay (1-2s) when post.file_ids is empty/null.
  • Test the fix with various file sizes and types to ensure the retry mechanism works correctly.
  • Consider adding logging or monitoring to detect and handle cases where the retry mechanism fails to obtain the populated file_ids.

Example

// extensions/mattermost/src/mattermost/monitor.ts
if (!post.file_ids || post.file_ids.length === 0) {
  setTimeout(() => {
    fetchMattermostPost(post.id).then((reFetchedPost) => {
      resolveMattermostMedia(reFetchedPost.file_ids);
    });
  }, 1000); // 1s delay
}

Notes

The proposed fix relies on the assumption that the file processing is completed within a short delay (1-2s). If the file processing takes longer, the retry mechanism may need to be adjusted accordingly.

Recommendation

Apply the workaround by implementing the proposed fix, as it addresses the known Mattermost server behavior and provides a reliable solution to detect file attachments.

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…
#api#authentication issue#prompt issue#agent setup#task chaining

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: bot does not see file attachments (file_ids empty in WebSocket event) [1 pull requests, 1 participants]