PR #72513: fix(mattermost): handle post_edited websocket events (#71930)

• Repository: openclaw/openclaw
• Author: Bojun-Vvibe
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/72513

Description (problem / solution / changelog)

Closes #71930.

Problem

In a Mattermost channel where the bot is already running, adding an @mention by editing an existing message never wakes the agent. The mention is simply ignored.

Root cause

The Mattermost WebSocket dispatcher at extensions/mattermost/src/mattermost/monitor-websocket.ts filters events by literal string match on event === "posted":

if (data.event === "posted") {
  // ... parse data.post, dispatch to onPosted
}
// any other event silently dropped

post_edited carries the full updated post body in data.post (same shape as posted — verified against the Mattermost server WebSocket event schema), but it never reaches the dispatcher branch. The agent has no way to learn that the message it ignored a moment ago now contains an @mention directed at it.

Reproducer

1. Configure OpenClaw on Mattermost with a bot user @openclawbot in some channel.
2. From a different account, post a message without mention: hello world.
3. Edit that message to add the mention: hello world @openclawbot.
4. Observe: bot does not react. Logs show posted events but no trace of the edit.

Fix

Route post_edited through the same parsePostedPayload → onPosted path as posted. Mattermost's post_edited payload carries the full updated post body in data.post (same shape as posted), so no new parsing is required.

Implementation:

// New seam: events that carry data.post and should be re-evaluated.
const POST_BEARING_EVENTS = new Set(["posted", "post_edited"]);

if (POST_BEARING_EVENTS.has(data.event)) {
  if (data.event === "post_edited") {
    log.debug(`mattermost: re-evaluating edited post ${postId} (post_edited)`);
  }
  // ... existing parse + dispatch path, unchanged
}

A debug log breadcrumb is emitted on the edit path so dropped vs. handled edits are diffable in logs (satisfies the issue's "at minimum, emit a warning log" ask).

Why not filter bot-self edits at the WS layer?

The bot-self loop concern (an assistant editing its own past replies) is already mitigated downstream:

• extensions/mattermost/src/mattermost/monitor.ts:1201 drops events where senderId === botUserId.
• The post debouncer keys on post.id, so an edit of an in-flight post replaces rather than double-fires.

The WebSocket layer is the wrong seam for that filter. The right move here is to stop dropping the event.

Verification

pnpm vitest run extensions/mattermost/src/mattermost/monitor-websocket.test.ts
# 12 passed (8 original + 4 new)

pnpm vitest run extensions/mattermost
# 363 passed across 37 mattermost test files, no regressions

pnpm check
# 0 errors, 0 warnings; all policy guards green

Tests added (4 new)

1. post_edited dispatch — event with full post body in data.post reaches onPosted; debug log re-evaluating edited post ... is emitted (regression for #71930).
2. posted backward-compat — still dispatches; no edit-log breadcrumb emitted on the non-edit path.
3. Bot-self post_edited — still forwarded at the WebSocket layer; downstream monitor.ts is responsible for filtering.
4. Malformed post_edited (missing data.post) — silently dropped, no crash, no error log.

Risk notes

• parsePostedPayload's name now slightly understates what it handles (it accepts both posted and post_edited). Did NOT rename to avoid cascading API churn (it's a public export). The POST_BEARING_EVENTS Set + comment block above documents the intent.
• post_deleted is NOT added — it carries a different payload shape (post_id only, no full body) and is out of scope for this PR.
• Diff: +18 lines in monitor-websocket.ts, +178 lines in tests.

Changed files

• extensions/mattermost/src/mattermost/monitor-websocket.test.ts (modified, +174/-0)
• extensions/mattermost/src/mattermost/monitor-websocket.ts (modified, +16/-2)