#Reaction errors in logs

1 messages · Page 1 of 1 (latest)

tropic kindle Mar 12, 2026, 9:43 AM

I am on openclaw v2026.3.7 and I noticed these errors in the logs

09:37:34 error telegram/api {"subsystem":"telegram/api"} telegram setMessageReaction failed: Call to 'setMessageReaction' failed! (400: Bad Request: REACTION_INVALID)
09:38:02 error telegram/api {"subsystem":"telegram/api"} telegram setMessageReaction failed: Call to 'setMessageReaction' failed! (400: Bad Request: REACTION_INVALID)

In my config, I thought I had already disabled the reactions but it got changed to minimal for some reason

"channels": {
"telegram": {
"enabled": true,
"dmPolicy": "allowlist",
"botToken": "...",
"allowFrom": [
"..."
],
"groupPolicy": "allowlist",
"streaming": "off",
"reactionLevel": "minimal"
}
},

ripe topazBOT Mar 12, 2026, 9:43 AM

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

spiral houndBOT Mar 12, 2026, 9:48 AM

That REACTION_INVALID is Telegram telling you “that emoji can’t be used as a reaction in this chat” (many groups/channels restrict the allowed reaction set). OpenClaw logs it as:

telegram/api … setMessageReaction failed … REACTION_INVALID

Two important nuances in config:

channels.telegram.reactionLevel is not the ack reaction.
It controls whether the agent is allowed to do “nice-to-have” reactions (tool action react). Also: if you omit it, the default is minimal (so it can look like it “changed” when config gets rewritten). Docs: https://docs.openclaw.ai/channels/telegram
The log line you pasted is very often from the ACK reaction (the 👀 while processing), which is controlled by:

channels.telegram.ackReaction (per-channel) / messages.ackReaction (global)
messages.ackReactionScope (when to do it)

If you want to fully stop Telegram reactions (and silence that log)

Disable the ack reaction for Telegram and also turn off agent reactions:

{
  channels: {
    telegram: {
      reactionLevel: "off",
      ackReaction: "",          // disables 👀 (or whatever) for Telegram
      actions: { reactions: false } // optional: hard-disable the react tool
    }
  }
  // optional global kill switch:
  // messages: { ackReactionScope: "off" }
}

If you do want the ack reaction, but Telegram rejects 👀

Pick an emoji that your Telegram chat actually allows as a reaction (check in the Telegram UI by long-pressing a message and seeing what reactions are offered), then set e.g.:

channels: { telegram: { ackReaction: "👍" } }

After changing config, restart the gateway (or rely on config hot-reload, but restart is the “no surprises” path): openclaw gateway restart.

tropic kindle Mar 12, 2026, 10:17 AM

Alright! another question. I am trying to setup webhook for telegram and it's not working. I will share the details over multiple messages to avoid the discord limit. I will let you know when I am done.

Here is the logs

openclaw-gateway-1  | 2026-03-12T10:08:37.239+00:00 [canvas] host mounted at http://0.0.0.0:18789/__openclaw__/canvas/ (root /home/node/.openclaw/canvas)
openclaw-gateway-1  | 2026-03-12T10:08:37.247+00:00 [gateway] ⚠️  Gateway is binding to a non-loopback address. Ensure authentication is configured before exposing to public networks.
openclaw-gateway-1  | 2026-03-12T10:08:37.251+00:00 [gateway] ⚠️  gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true is enabled. Host-header origin fallback weakens origin checks and should only be used as break-glass.
openclaw-gateway-1  | 2026-03-12T10:08:37.345+00:00 [heartbeat] started
openclaw-gateway-1  | 2026-03-12T10:08:37.358+00:00 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
openclaw-gateway-1  | 2026-03-12T10:08:37.366+00:00 [gateway] agent model: google/gemini-3-flash-preview
openclaw-gateway-1  | 2026-03-12T10:08:37.370+00:00 [gateway] listening on ws://0.0.0.0:18789 (PID 7)
openclaw-gateway-1  | 2026-03-12T10:08:37.376+00:00 [gateway] log file: /tmp/openclaw/openclaw-2026-03-12.log
openclaw-gateway-1  | 2026-03-12T10:08:37.465+00:00 [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)
openclaw-gateway-1  | 2026-03-12T10:08:37.731+00:00 [telegram] [default] starting provider (@CarlaTheAwesomeBot)
openclaw-gateway-1  | 2026-03-12T10:08:37.743+00:00 [telegram] autoSelectFamily=true (default-node22)

openclaw-gateway-1  | 2026-03-12T10:08:37.746+00:00 [telegram] dnsResultOrder=ipv4first (default-node22)
openclaw-gateway-1  | 2026-03-12T10:08:38.100+00:00 [telegram] webhook local listener on http://127.0.0.1:8788/telegram-webhook
openclaw-gateway-1  | 2026-03-12T10:08:38.103+00:00 [telegram] webhook advertised to telegram on https://claw.server.ahmedsaed.me/telegram-webhook
openclaw-gateway-1  | 2026-03-12T10:08:52.478+00:00 [ws] Proxy headers detected from untrusted address. Connection will not be treated as local. Configure gateway.trustedProxies to restore local client detection behind your proxy.
openclaw-gateway-1  | 2026-03-12T10:08:52.575+00:00 [ws] security warning: websocket origin accepted via Host-header fallback conn=21159c21-9f86-404e-8b55-75d2fc3eedca count=1 host=claw.ahmedsaed.me origin=https://claw.ahmedsaed.me
openclaw-gateway-1  | 2026-03-12T10:08:52.579+00:00 [gateway] security metric: gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback accepted a websocket connect request
openclaw-gateway-1  | 2026-03-12T10:08:52.605+00:00 [ws] webchat connected conn=21159c21-9f86-404e-8b55-75d2fc3eedca remote=172.18.0.1 client=openclaw-control-ui webchat v2026.3.7
openclaw-gateway-1  | 2026-03-12T10:08:52.781+00:00 [ws] ⇄ res ✓ node.list 52ms conn=21159c21…edca id=a404ffb3…5432
openclaw-gateway-1  | 2026-03-12T10:08:52.789+00:00 [ws] ⇄ res ✓ device.pair.list 59ms conn=21159c21…edca id=eb776277…ded5
openclaw-gateway-1  | 2026-03-12T10:08:52.875+00:00 [ws] ⇄ res ✓ chat.history 149ms conn=21159c21…edca id=2c2d5429…ccdb

openclaw-gateway-1  | 2026-03-12T10:09:49.325+00:00 [ws] ⇄ res ✓ config.schema 1308ms conn=21159c21…edca id=3b73de41…5520
openclaw-gateway-1  | 2026-03-12T10:09:49.992+00:00 [ws] ⇄ res ✓ channels.status 1978ms conn=21159c21…edca id=d4444d0a…7f94
openclaw-gateway-1  | 2026-03-12T10:09:52.851+00:00 [ws] ⇄ res ✓ config.get 59ms conn=21159c21…edca id=5fe19115…9f68
openclaw-gateway-1  | 2026-03-12T10:09:53.114+00:00 [ws] ⇄ res ✓ channels.status 331ms conn=21159c21…edca id=0d2fe456…f5e4
openclaw-gateway-1  | 2026-03-12T10:10:01.253+00:00 [ws] ⇄ res ✓ chat.history 62ms conn=21159c21…edca id=49240cad…162c
openclaw-gateway-1  | 2026-03-12T10:11:24.715+00:00 [ws] ⇄ res ✓ channels.status 686ms conn=21159c21…edca id=a3a073ce…6359
openclaw-gateway-1  | 2026-03-12T10:11:34.071+00:00 [ws] ⇄ res ✓ channels.status 430ms conn=21159c21…edca id=5749efee…a91a
openclaw-gateway-1  | 2026-03-12T10:11:37.338+00:00 [ws] ⇄ res ✓ chat.history 73ms conn=21159c21…edca id=4b5b1e02…dbd8
openclaw-gateway-1  | 2026-03-12T10:11:40.060+00:00 [ws] ⇄ res ✓ config.get 64ms conn=21159c21…edca id=4e427c49…b7a6
openclaw-gateway-1  | 2026-03-12T10:11:40.348+00:00 [ws] ⇄ res ✓ channels.status 365ms conn=21159c21…edca id=5d90ae17…6d7f

I have updated the docker compose file to include

    ports:
      - "${OPENCLAW_GATEWAY_PORT:-18789}:18789"
      - "${OPENCLAW_BRIDGE_PORT:-18790}:18790"
      - "${OPENCLAW_TELEGRAM_PORT:-8788}:8788"

In the env, I have defined

OPENCLAW_TELEGRAM_PORT=8788

In the openclaw config json file

  "channels": {
    "telegram": {
      "enabled": true,
      "dmPolicy": "allowlist",
      "botToken": "...",
      "allowFrom": [
        "tg:1359334095"
      ],
      "groupPolicy": "allowlist",
      "streaming": "off",
      "reactionLevel": "minimal",
      "webhookUrl": "https://claw.server.ahmedsaed.me/telegram-webhook",
      "webhookSecret": "...",
      "webhookPort": 8788
    }
  },

In nginx, I have set https://claw.server.ahmedsaed.me/to point to my server ip and port 8788. What could be wrong. Done. your turn

spiral houndBOT Mar 12, 2026, 10:19 AM

Got it — keep sending the rest, but from the snippet you posted so far I don’t actually see any “webhook mode” lines yet (it still looks like it’s just starting the Telegram provider).

When you’re done dumping info, can you include these 3 things (they usually reveal the exact break):

Your Telegram webhook config block (redact secrets, but keep the keys/shape):

channels.telegram.webhookUrl
channels.telegram.webhookSecret (present? empty? just say “set”)
optional: webhookHost, webhookPort, webhookPath

How port 8787 is exposed in Docker / reverse proxy

By default the webhook listener binds to 127.0.0.1:8787 (inside the container), so if you’re fronting it with nginx/traefik/caddy or a host-level proxy, you typically need:
- channels.telegram.webhookHost: "0.0.0.0" and
- publish/map container port 8787 (or proxy to it on the docker network)

The log lines around webhook registration
In webhook mode, OpenClaw logs these on startup:

webhook local listener on http://<host>:<port>/telegram-webhook

webhook advertised to telegram on <publicUrl>
If startup fails, there will be a telegram setWebhook failed: ... error before those.

Quick sanity checks (often clarifies things immediately):

Telegram generally requires HTTPS for webhookUrl (unless you upload a cert).
Hitting the webhook path with a browser/curl will usually 404/401 (normal). The health endpoint is GET /healthz on the webhook listener port.

Send the next chunk whenever — once I see your webhookUrl + how you’re routing to 8787, we can zero in fast.

Those two lines are actually good news:

webhook local listener on http://127.0.0.1:8788/telegram-webhook
webhook advertised to telegram on https://claw.server.ahmedsaed.me/telegram-webhook

That means OpenClaw did start the webhook server and setWebhook succeeded.

When webhook “doesn’t work” after that, it’s almost always one of these:

1) Your reverse proxy is forwarding `/telegram-webhook` to the wrong port

The webhook listener is on port 8788, not the gateway port 18789.

So your proxy for the public URL must route:

https://claw.server.ahmedsaed.me/telegram-webhook → http://<openclaw-container>:8788/telegram-webhook

(optional sanity check) https://claw.server.ahmedsaed.me/healthz → http://<openclaw-container>:8788/healthz

If you proxy /telegram-webhook to 18789, Telegram will hit the Gateway/UI server instead, and updates won’t be processed.

2) You’re binding the webhook listener to `127.0.0.1` inside the container

Your log says it’s listening on 127.0.0.1:8788. In Docker, that’s loopback of the container, so a different container (nginx/traefik/caddy) or the host often can’t reach it.

Fix: set the webhook listener to bind on all interfaces:

channels: {
  telegram: {
    webhookHost: "0.0.0.0",
    webhookPort: 8788,
  }
}

…and make sure port 8788 is reachable from whatever is proxying it (docker network route or a published port).

Docs reference: https://docs.openclaw.ai/channels/telegram (Long polling vs webhook section)

Fastest way to see what Telegram thinks is wrong

Run Telegram’s webhook status call (it will tell you last error + pending updates):

getWebhookInfo on your bot token (redact the token when pasting). Look for:

last_error_message
last_error_date
pending_update_count

If you paste that output + your reverse proxy snippet for the /telegram-webhook route, I can tell you exactly which of the two issues above it is.

Nice — the port publish is the right move, but there’s one critical gotcha here:

Your webhook server is still binding to 127.0.0.1 inside the container:

webhook local listener on http://127.0.0.1:8788/telegram-webhook

In Docker, publishing 8788:8788 forwards traffic to the container’s eth0 IP, not its loopback. So if the process only listens on 127.0.0.1, connections coming in via the published port will fail (nothing is listening on 0.0.0.0:8788).

Fix

Set the webhook listener to bind on all interfaces:

{
  channels: {

    telegram: {
      webhookHost: "0.0.0.0",
      webhookPort: 8788,
      // webhookUrl + webhookSecret as you already have
    }
  }
}

Restart the container, and you should then see a log more like:

webhook local listener on http://0.0.0.0:8788/telegram-webhook

Quick sanity checks

After restart:

From inside the container:
- curl -i http://127.0.0.1:8788/healthz → should return 200 ok
From the host (since you published the port):
- curl -i http://127.0.0.1:8788/healthz → should also return 200 ok

If that works, Telegram connectivity becomes the next check: run getWebhookInfo and look at last_error_message / pending_update_count (it’ll immediately tell us if Telegram can reach it and whether it’s getting 401/404/timeouts).

One more note: OPENCLAW_TELEGRAM_PORT=8788 is fine for docker-compose templating, but OpenClaw itself won’t automatically read that env var for webhookPort unless you’ve explicitly wired it into the JSON5 config—so the config value is still the source of truth.

What’s wrong is very likely this: you never set webhookHost, so OpenClaw is still binding the webhook listener to 127.0.0.1 inside the container.

That produces exactly what you saw earlier:

webhook local listener on http://127.0.0.1:8788/telegram-webhook

In Docker, publishing 8788:8788 (or proxying to host:8788) forwards traffic to the container’s eth0 address, not its loopback. So Telegram/nginx can hit the published port all day, but nothing is actually listening on 0.0.0.0:8788 inside the container → webhook appears “dead”.

Fix in OpenClaw config

Add:

channels: {
  telegram: {
    webhookHost: "0.0.0.0",
    webhookPort: 8788,

}
}

Restart the gateway container and confirm the log changes to something like:

webhook local listener on http://0.0.0.0:8788/telegram-webhook

Also double-check your nginx upstream scheme + path handling

The OpenClaw webhook listener is plain HTTP, so nginx must proxy with http://, not https://.

A known-good pattern is:

location = /healthz {

  proxy_pass http://127.0.0.1:8788/healthz;
}

location = /telegram-webhook {
  proxy_pass http://127.0.0.1:8788/telegram-webhook;
  proxy_http_version 1.1;
  proxy_set_header Host $host;
}

(If you instead do proxy_pass https://...:8788 you’ll get TLS-to-backend failures.)

Quick proof it’s working

After the change, hitting this from outside should return ok:

https://claw.server.ahmedsaed.me/healthz

And getWebhookInfo should stop showing connection errors / pending updates.

If you paste your getWebhookInfo output (redact token), I can tell you immediately whether Telegram is seeing 401 (secret header stripped), 404 (path rewrite), or connection refused (bind/port).

tropic kindle Mar 12, 2026, 10:38 AM

working now. it was the webhook host configuration that was missing.