Summary

• Problem: WhatsApp reactions require the model to explicitly provide messageId, unlike Telegram, Signal, and Discord which auto-resolve it from inbound context via the shared resolveReactionMessageId helper.
• Why it matters: The model can't simply call message({ action: "react", emoji: "👍" }) to react to the current inbound message — it must echo back the message ID from context, which it often fails to do.
• What changed: Wired resolveReactionMessageId from openclaw/plugin-sdk/channel-actions into the WhatsApp handleAction adapter with safety guards for cross-chat and cross-provider scenarios.
• What did NOT change (scope boundary): No transport changes (sendReactionWhatsApp, send-api.ts), no schema changes (message-tool.ts), no config changes. The react action was already declared by describeMessageTool.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Related: Telegram equivalent landed in c1b75ab (PR fix(telegram): make reaction handling soft-fail and message-id resilient #20236), shared helper extracted in 7066d5e
• This PR fixes a bug or regression

Root Cause / Regression History (if applicable)

N/A — This is a new feature, not a fix. WhatsApp reactions were added (551a8d5, Jan 6 2026) with messageId: required and never updated when Telegram got the context fallback (c1b75ab, Feb 23 2026) or when the shared helper was extracted (7066d5e, Mar 2 2026).

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: extensions/whatsapp/src/channel.test.ts
• Scenario the test should lock in:
  • Explicit messageId wins over context fallback
  • Omitted messageId falls back to toolContext.currentMessageId (WhatsApp source only)
  • Numeric messageId converted to string
  • Missing messageId with no context throws ToolInputError (400, not 500)
  • Cross-chat targeting suppresses fallback (normalized comparison handles whatsapp:+1555 vs +1555)
  • Cross-provider source (e.g. Telegram) suppresses fallback
• Why this is the smallest reliable guardrail: Tests exercise the adapter layer in channel.ts where the fallback logic lives, mocking the runtime to verify parameter resolution.

User-visible / Behavior Changes

• The model can now react to the current WhatsApp inbound message by calling message({ action: "react", emoji: "👍" }) without providing messageId — it auto-resolves from context.
• Explicit messageId still works as before (no breaking change).
• Requires message tool to be available (e.g. messaging profile or tools.alsoAllow: ["message"]).

Diagram (if applicable)

Before:
model calls message({ action: "react", emoji: "👍" })
  → ToolInputError: messageId required

After:
model calls message({ action: "react", emoji: "👍" })
  → resolveReactionMessageId falls back to toolContext.currentMessageId
  → sendReactionWhatsApp(chatJid, inboundMsgId, "👍")
  → reaction appears on user's message

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No — react action was already declared and gated by channels.whatsapp.actions.reactions
• Data access scope changed? No
• Guards: fallback only fires when source is WhatsApp AND target is the same chat (normalized). Cross-chat and cross-provider contexts require explicit messageId.

Repro + Verification

Environment

• OS: Linux (Ubuntu)
• Runtime/container: Node 22, pnpm
• Model/provider: Anthropic claude-sonnet-4-5
• Integration/channel: WhatsApp (Baileys)
• Relevant config: tools.profile: "messaging", channels.whatsapp.actions.reactions: true (default)

Steps

1. Send a WhatsApp message to the bot
2. In the same conversation, tell the bot: "React to my previous message with 👍"
3. Bot calls message({ action: "react", emoji: "👍" }) — no messageId needed

Expected

• Emoji reaction appears on the user's WhatsApp message

Actual

• Emoji reaction appears on the user's WhatsApp message ✓

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Live-tested on OpenClaw 2026.3.28 (cherry-picked) with WhatsApp DM. Gateway logs confirm tool=message called and reaction delivered. 7 new unit tests in channel.test.ts cover fallback, cross-chat guard, cross-provider guard, and error type preservation.

Human Verification (required)

• Verified scenarios: DM reaction with omitted messageId (auto-resolved from context), explicit messageId still works
• Edge cases checked: cross-chat targeting (different to vs currentChannelId with prefix normalization), cross-provider source (Telegram context), missing messageId without context (ToolInputError 400)
• What you did not verify: Group reactions (require participant field — pre-existing limitation, not introduced by this change)

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes — explicit messageId still works identically
• Config/env changes? No
• Migration needed? No

Risks and Mitigations

• Risk: Group reactions may fail when messageId is auto-resolved but participant is missing (needed for group message keys).
  • Mitigation: Pre-existing limitation — same behavior as before for groups. participant enrichment from context is a follow-up enhancement.