fix(mattermost): properly resolve ambiguous target IDs and enable image recognition [AI-assisted] by webclerk · Pull Request #22594 · openclaw/openclaw

webclerk · 2026-02-21T10:48:26Z

Summary

This PR contains two fixes for the Mattermost integration:

Properly resolve ambiguous target IDs via graceful fallback - Fixes an issue where 26-character user IDs without a prefix were incorrectly assumed to be channel IDs, leading to 403 Forbidden errors.
Enable image recognition with SSRF policy - Adds SSRF policy configuration to allow fetching media files from the Mattermost server hostname, enabling proper image recognition.

Changes

Target ID Resolution

Changed normalizeMattermostMessagingTarget to return unprefixed IDs as-is instead of auto-adding channel: prefix
Added kind: "unknown" target type to represent ambiguous IDs
Modified parseMattermostTarget to classify unprefixed IDs as "unknown" instead of "channel"
Implemented try-catch fallback in resolveTargetChannelId to probe channel existence before falling back to user ID resolution

Image Recognition Support

Added ssrfPolicy parameter with allowed hostname when fetching media files
Enables the monitor to properly download and recognize images from Mattermost server

Testing

Tested locally with Mattermost instance
Verified ambiguous IDs (users/channels) are correctly resolved
Verified image recognition now works correctly with the SSRF policy in place
Both fixes have been validated in a real Mattermost environment

AI-Assisted Note

Mark as AI-assisted
Fully tested
Code reviewed and understood by contributor
AI tool used: Claude Sonnet 4.6

What & Why

Target ID Resolution

The Mattermost plugin was incorrectly treating all 26-character unprefixed IDs as channel IDs. This caused 403 errors when users tried to interact with direct message channels using user IDs. The fix implements a graceful fallback pattern that probes the ID type and falls back appropriately.

Image Recognition Support

The Mattermost monitor was unable to fetch images due to missing SSRF policy. This fix adds the required ssrfPolicy configuration to allow downloading media files from the configured Mattermost server hostname, which is essential for image recognition features.

Both fixes work together to provide a complete and robust Mattermost integration experience.

…allback

Add ssrfPolicy configuration to allow fetching media files from the Mattermost server hostname, enabling proper image recognition. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

tonydehnke · 2026-02-24T04:07:18Z

Hey @webclerk, thanks for working on this! A few observations from our work on #19957 (interactive buttons + directory adapter) which touches the same normalize.ts file:

`#channel-name` path is unchanged

The normalizeMattermostMessagingTarget change on line 31 fixes bare names (return trimmed instead of return channel:${trimmed}), but the #channel branch at lines 28-29 is untouched — it still returns channel:name. This means #bookmarks resolves to channel:bookmarks, which passes the looksLikeId check and gets sent directly as a channel ID → 403 Forbidden (since bookmarks is a name, not a 26-char Mattermost ID).

In #19957 we return undefined for both #channel and bare names, which triggers the core's directory adapter to resolve the name to its actual Mattermost channel ID.

Silent error swallowing

The catch (e) { // Ignored } fallback in resolveTargetChannelId will mask real errors (expired tokens, network failures, rate limits). If the channel lookup fails for a non-404 reason, it silently falls through to treating the ID as a user — which will also fail, but with a confusing error about DM creation rather than the real cause.

`looksLikeMattermostTargetId` still loose

The existing {8,} regex matches short strings like "password" or "username". In #19957 we tightened this to strict 26-char alnum (Mattermost's actual ID format) plus the abc123__xyz789 DM channel pattern.

SSRF policy — great idea

The ssrfPolicy: { allowedHostnames: [...] } addition for media downloads is a genuinely useful fix that's independent of the target resolution changes. We're going to add this to #19957 as well (with credit to this PR). Nice catch!

These PRs will conflict on normalize.ts if both merge. Happy to coordinate — the approaches are complementary and the SSRF fix is valuable regardless of which normalize approach lands.

@webclerk