PR #72025: fix(signal): enable inbound status reactions

• Repository: openclaw/openclaw
• Author: Hua688
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/72025

Description (problem / solution / changelog)

Summary

Describe the problem and fix in 2-5 bullets:

• Problem: Signal has reaction send helpers, but inbound runs never wired messages.statusReactions.enabled into the shared status reaction lifecycle.
• Why it matters: Signal users get no queued/thinking/tool/compacting/done/error visual feedback during long-running agent turns even when status reactions are configured.
• What changed: Create a Signal status reaction controller for eligible inbound messages, route lifecycle callbacks through dispatchInboundMessage, and send reactions via sendReactionSignal for direct and group messages.
• What did NOT change (scope boundary): No config shape changes, no Signal REST/native transport changes, and no agent/tool message-action behavior changes.

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

• Closes #72020
• Related #20393
• Related #65919
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: Signal's inbound handler dispatched messages without creating a StatusReactionController or passing lifecycle callbacks (onReplyStart, onToolStart, compaction callbacks, terminal state handling) into dispatchInboundMessage.
• Missing detection / guardrail: Signal had send-reaction helper tests, but no inbound regression test for messages.statusReactions.enabled.
• Contributing context (if known): Other channels already wire the shared status reaction controller; Signal had the transport primitive but not the inbound lifecycle wiring.

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/signal/src/monitor/event-handler.status-reactions.test.ts
• Scenario the test should lock in: Signal direct and group inbound messages with messages.statusReactions.enabled send queued and done reactions through the correct direct recipient or groupId/targetAuthor route.
• Why this is the smallest reliable guardrail: It exercises the Signal inbound handler, dispatch callback wiring, and Signal reaction transport seam without needing a live Signal daemon.
• Existing test that already covers this (if any): N/A
• If no new test is added, why not: N/A

User-visible / Behavior Changes

Signal now honors messages.statusReactions.enabled for inbound runs by updating reactions on the triggering message during the agent lifecycle.

Diagram (if applicable)

Before:
Signal inbound -> dispatchInboundMessage -> no status reaction callbacks -> no lifecycle reactions

After:
Signal inbound -> StatusReactionController -> dispatch lifecycle callbacks -> sendReactionSignal -> queued/done status reactions

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: Linux / Ubuntu 24.04
• Runtime/container: Node 22 + pnpm checkout
• Model/provider: N/A for regression test
• Integration/channel (if any): Signal
• Relevant config (redacted):

{
  "messages": {
    "ackReaction": "👀",
    "ackReactionScope": "all",
    "statusReactions": {
      "enabled": true
    }
  },
  "channels": {
    "signal": {
      "dmPolicy": "open",
      "allowFrom": ["*"]
    }
  }
}

Steps

1. Configure Signal with messages.statusReactions.enabled: true.
2. Send a Signal DM or allowed Signal group message that triggers an agent run.
3. Observe reactions on the inbound message during processing and completion.

Expected

• Signal sends lifecycle status reactions such as queued/ack and done (plus intermediate thinking/tool/compacting when those callbacks fire).

Actual

• Before this fix, Signal sent no automatic lifecycle status reactions because the inbound dispatch path did not wire status reaction callbacks.

Evidence

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

Targeted verification:

• pnpm test extensions/signal/src/monitor/event-handler.status-reactions.test.ts
• pnpm lint:extensions

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios: Direct Signal inbound status reaction routing and group Signal inbound status reaction routing through the new regression test.
• Edge cases checked: Direct recipient uses sender recipient; group reaction uses empty recipient plus groupId and targetAuthor.
• What you did not verify: Live Signal daemon/container end-to-end reaction delivery.

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.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: Signal reaction API failures could add noisy logs during long runs.
  • Mitigation: Reaction send failures are caught and logged through existing verbose logging; they do not fail message dispatch.

Changed files

• extensions/signal/src/monitor/event-handler.status-reactions.test.ts (added, +222/-0)
• extensions/signal/src/monitor/event-handler.ts (modified, +123/-13)