- Bot reacts with 👀 when receiving a message (ack) - Reaction changes to 🤔/👨💻 during processing - Final reaction is 👍 (done) or 💔 (error)

openclaw - ✅(Solved) Fix [Telegram] statusReactions + ackReaction not firing on OpenClaw 2026.4.5 [1 pull requests, 1 participants]

iygge · 2026-04-17T00:16:20Z

[openclaw] PR 67890: Doctor/config: repair misplaced channels. .messages.* (fixes #67859) - Repository: openclaw/openclaw - Author: neeravmakwana - State: closed | merged: False - Link: https://github.com/openclaw/openclaw/pull/67890 ## Description (problem / solution / changelog) ## Summary - Problem: Users who nest reaction config under `channels. .messages.*` (for example the reporter's \`channels.telegram.messages.statusReactions\` / \`ackReaction\` / \`ackReactionScope\`) observe no ack reaction and no status reactions. The runtime only reads these keys from top-level \`messages.*\` (plus \`channels. .ackReaction\` / \`.responsePrefix\` for the two channel-scoped variants), so the nested keys are silently dropped with no user-visible signal. - Why it matters: There is no actionable error today — config validates (the top-level \`ChannelsSchema\` uses \`passthrough()\`) and the channel boots, the bot just never reacts. The reporter (and this is not the first time this path confuses users) has no way to self-diagnose the mismatch. - What changed: New \`openclaw doctor --fix\` legacy-config migration \`channels. .messages->messages\` that detects misplaced \`channels. .messages.*\` and \`channels. .accounts. .messages.*\` blocks and relocates each known \`MessagesConfig\` key to its canonical location. Channel-scoped keys (\`ackReaction\`, \`responsePrefix\`) stay on the channel/account scalar so the user's per-channel intent is preserved; the other \`MessagesConfig\` keys (\`ackReactionScope\`, \`removeAckAfterReply\`, \`statusReactions\`, \`suppressToolErrors\`, \`messagePrefix\`, \`groupChat\`, \`queue\`, \`inbound\`, \`tts\`) land at top-level \`messages.*\`. Covers both channel-level and account-level misplacement; honors existing destination values (logs a removed note instead of clobbering); never touches unknown keys (third-party plugin config is preserved). - What did NOT change (scope boundary): No changes to the reaction pipeline itself — \`resolveAckReaction\`, \`shouldAckReactionGate\`, and \`createStatusReactionController\` still read from the same canonical locations they already did. No changes to channel/message schemas, defaults, runtime gating, or SDK surface. No config keys were retired, added, or aliased into the public contract. ## Change Type (select all) - [x] Bug fix - [ ] Feature - [ ] Refactor required for the fix - [x] Docs - [ ] Security hardening - [ ] Chore/infra ## Scope (select all touched areas) - [x] Gateway / orchestration - [ ] Skills / tool execution - [ ] Auth / tokens - [ ] Memory / storage - [ ] Integrations - [ ] API / contracts - [ ] UI / DX - [ ] CI/CD / infra ## Linked Issue/PR - Closes #67859 - [x] This PR fixes a bug or regression ## Root Cause (if applicable) - Root cause: No schema rejects \`channels. .messages\` (the outer \`ChannelsSchema\` is \`passthrough()\` to tolerate third-party channel configs), and no runtime code path reads from that nested location — runtime reads \`cfg.messages.ackReactionScope\`, \`cfg.messages.statusReactions\`, \`cfg.messages.removeAckAfterReply\` (see \`extensions/telegram/src/bot.ts\` and \`extensions/telegram/src/bot-message-context.ts\`) and \`resolveAckReaction\` (see \`src/agents/identity.ts\`). The result: misplaced keys are silently ignored with no repair signal. - Missing detection / guardrail: Doctor had no migration spec for this shape, so \`openclaw doctor\` did not flag or repair it. - Contributing context: The reporter's JSON looks intuitively \"Telegram-scoped\", but the actual contract keeps \`messages\` globally at the top level and exposes per-channel \`ackReaction\` / \`responsePrefix\` scalars at \`channels. .*\` (not under a \`messages\` sub-object). ## Regression Test Plan (if applicable) - Coverage level that should have caught this: [x] Unit test - Target test or file: \`src/commands/doctor/shared/legacy-config-migrations.channel-messages.test.ts\` - Scenario the test should lock in: Config with misplaced \`channels. .messages.*\` (channel-level) and \`channels. .accounts. .messages.*\` (account-level) is migrated to canonical locations; destination-already-set paths are honored; unknown third-party keys are preserved; non-record top-level \`messages\` is never clobbered. - Why this is the smallest reliable guardrail: Drives the migration through the production aggregator (\`LEGACY_CONFIG_MIGRATIONS\`) with raw \`unknown\` input and asserts the exact post-migration shape plus \`changes\` strings. No mocks, no helper defaults. - Existing test that already covers this (if any): None. ## User-visible / Behavior Changes - \`openclaw doctor\` now warns when \`channels. .messages.*\` or \`channels. .accounts. .messages.*\` is present. - \`openclaw doctor --fix\` (and \`--repair\`) now repairs those configs in

openclaw2026-04-17 00:16:20

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.

GitHub issue URL

Helpful · Quick feedback

GitHub stats

openclaw/openclaw#67859•Fetched 2026-04-17 08:29:15

View on GitHub

Comments

Participants

Timeline

Reactions

Author

iygge

Participants

iygge

Timeline (top)

cross-referenced ×1unsubscribed ×1

Error Message

"error": "💔",

Final reaction is 👍 (done) or 💔 (error)
#45906 — statusReactions shows error emoji even for success (implies it DOES fire for some users) Is channels.telegram.messages the correct path for this config? Or does it belong elsewhere (e.g., agents.defaults.messages)? We tried agents.defaults.messages but got "Unrecognized key" validation error.

Code Example

"channels": {
  "telegram": {
    "messages": {
      "ackReaction": "👀",
      "ackReactionScope": "all",
      "removeAckAfterReply": true,
      "statusReactions": {
        "enabled": true,
        "emojis": {
          "thinking": "🤔",
          "tool": "👨‍💻",
          "coding": "✍",
          "web": "🔥",
          "done": "👍",
          "error": "💔",
          "stallSoft": "😴",
          "stallHard": "😱",
          "compacting": "🤓"
        }
      }
    }
  }
}

---

curl -X POST "https://api.telegram.org/bot<token>/setMessageReaction" \
    -H "Content-Type: application/json" \
    -d '{"chat_id": <id>, "message_id": <id>, "reaction": [{"type": "emoji", "emoji": "👍"}]}'
  → {"ok":true,"result":true}

RAW_BUFFERClick to expand / collapse

Environment

OpenClaw version: 2026.4.5 (3e72c03)
Platform: Ubuntu 22.04 (VPS)
Channel: Telegram (bot as group admin)
Model: openai-codex/gpt-5.4

Config

"channels": {
  "telegram": {
    "messages": {
      "ackReaction": "👀",
      "ackReactionScope": "all",
      "removeAckAfterReply": true,
      "statusReactions": {
        "enabled": true,
        "emojis": {
          "thinking": "🤔",
          "tool": "👨‍💻",
          "coding": "✍",
          "web": "🔥",
          "done": "👍",
          "error": "💔",
          "stallSoft": "😴",
          "stallHard": "😱",
          "compacting": "🤓"
        }
      }
    }
  }
}

Expected behavior

Bot reacts with 👀 when receiving a message (ack)
Reaction changes to 🤔/👨‍💻 during processing
Final reaction is 👍 (done) or 💔 (error)

Actual behavior

No reactions at all. Zero. Silent.
Config validates successfully (openclaw config validate → valid)
No errors in logs related to reactions

Confirmed working

setMessageReaction API works when called manually via curl:

curl -X POST "https://api.telegram.org/bot<token>/setMessageReaction" \
  -H "Content-Type: application/json" \
  -d '{"chat_id": <id>, "message_id": <id>, "reaction": [{"type": "emoji", "emoji": "👍"}]}'
→ {"ok":true,"result":true}

Bot is admin in the group with can_manage_chat: true
All emojis used are valid Telegram reaction emojis

Related issues

#45906 — statusReactions shows error emoji even for success (implies it DOES fire for some users)
#27073 — reactions fail silently on long messages (closed/stale)

Question

Is channels.telegram.messages the correct path for this config? Or does it belong elsewhere (e.g., agents.defaults.messages)? We tried agents.defaults.messages but got "Unrecognized key" validation error.

extent analysis

TL;DR

The issue is likely due to an incorrect configuration path for the Telegram reaction settings, and verifying the correct path is necessary to resolve the issue.

Guidance

Review the OpenClaw documentation to confirm the correct configuration path for Telegram reaction settings, as the current path channels.telegram.messages may not be accurate.
Check if there are any other configuration options or overrides that could be affecting the reaction settings, such as agents.defaults.messages or other channel-specific settings.
Verify that the statusReactions setting is enabled and properly configured, as it may be related to the issue.
Test the reaction settings with a minimal configuration to isolate the issue and determine if it's specific to the current setup.

Example

No code snippet is provided as it's not clearly supported by the issue, but an example of a minimal configuration for testing could be:

"channels": {
  "telegram": {
    "messages": {
      "ackReaction": "👀",
      "statusReactions": {
        "enabled": true
      }
    }
  }
}

Notes

The issue may be related to the statusReactions setting, which is mentioned in a related issue (#45906). Additionally, the fact that the setMessageReaction API works manually via curl suggests that the issue is likely with the configuration rather than the Telegram API.

Recommendation

Apply a workaround by testing different configuration paths and settings to determine the correct configuration for the Telegram reaction settings, as the current path may not be accurate.

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?

FAQ

Expected behavior

Bot reacts with 👀 when receiving a message (ack)
Reaction changes to 🤔/👨‍💻 during processing
Final reaction is 👍 (done) or 💔 (error)

#api #API rate limit #retriever error #indexing error #inference speed

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

openclaw - ✅(Solved) Fix [Telegram] statusReactions + ackReaction not firing on OpenClaw 2026.4.5 [1 pull requests, 1 participants]

Recommended Tools

GitHub issue graph ai analysis

Error Message

Fix Action

Fixed

PR fix notes

PR #67890: Doctor/config: repair misplaced channels.<id>.messages.* (fixes #67859)

Description (problem / solution / changelog)

Summary

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Root Cause (if applicable)

Regression Test Plan (if applicable)

User-visible / Behavior Changes

Diagram (if applicable)

Security Impact (required)

Repro + Verification

Environment

Steps

Expected

Actual

Evidence

Human Verification (required)

Review Conversations

Compatibility / Migration

Risks and Mitigations

Changed files

Code Example

Environment

Config

Expected behavior

Actual behavior

Confirmed working

Related issues

Question

extent analysis

TL;DR

Guidance

Example

Notes

Recommendation

FAQ

Expected behavior

Still need to ship something?

RELATED_DISCOVERY

TRENDING