#Telegram Group Chat Issue

1 messages · Page 1 of 1 (latest)

lunar ibex May 11, 2026, 10:21 PM

ersion: 2026.4.27 | Channel: Telegram | Host: Ubuntu 24.04 VPS

Symptom: Forum group chats silently drop inbound messages. Bot shows typing indicator but never responds. DMs work fine. Affects older forum groups but NOT a newly created forum group (same config).

Key findings:

• Update offset advances when group messages sent → OpenClaw IS fetching the updates
• Typing indicator appears → something begins processing
• Zero log output → message dropped before agent routing, no drop/filter line visible
• 3 forum groups: 2 older ones broken, 1 created today works fine
• DMs work, direct sendMessage API calls return ok:true, no webhook, bot is admin, Group Privacy disabled

Hypothesis: Recent Telegram changes to forum/topic group update format (message_thread_id / is_topic_message for older supergroups) may be causing silent drops after fetch.

Questions:

Known issue with forum group inbound in 2026.4.27 related to recent Telegram changes?
Any debug flag to see why a fetched update is dropped before agent routing?
Could older vs newer forum group update formats cause this?

waxen nightBOT May 11, 2026, 10:23 PM

I checked current source/docs. This does look plausibly fixed after 2026.4.27, not just a config issue.

Known issue? I don’t see it documented as “recent Telegram API change”, but main has a post-2026.4.27 fix named fix telegram topic bottleneck. The key bit: 2026.4.27 only treated a supergroup as forum/topic-aware in the Telegram sequential queue when chat.is_forum was present. Current code also treats is_topic_message: true + message_thread_id as topic-aware. That matches your older-vs-newer forum group suspicion pretty closely.
Debug visibility: yes — set file logging to debug, then reproduce:

openclaw config set logging.level debug
openclaw gateway restart
openclaw logs --follow | grep -Ei 'telegram update|telegram dedupe|Blocked telegram|skipping group|handler failed|sendChatAction|topic'

Debug logging should show raw Telegram update previews and verbose drop/dedupe lines. Be careful sharing those logs: raw update previews can include message text/usernames.

For HTTP-level Telegram API calls, also useful:

openclaw config set diagnostics.flags '["telegram.http"]'
openclaw gateway restart

Docs: https://docs.openclaw.ai/diagnostics/flags and https://docs.openclaw.ai/gateway/logging

Older vs newer format? Yes, that’s credible. If the broken older forum groups send updates with is_topic_message: true / message_thread_id but missing chat.is_forum, 2026.4.27 can put them on the base group lane instead of :topic:<id>. That can look like “typing starts, then nothing”, especially with topic/group queue bottlenecking.

Recommended next step: upgrade past 2026.4.27 and restart the gateway:

pnpm add -g openclaw@latest
openclaw gateway restart
openclaw --version

If it still reproduces on latest, please file a GitHub issue with redacted paired getUpdates samples from one broken old forum group and the working newly-created forum group, especially these fields: chat.id, chat.type, chat.is_forum, message_thread_id, is_topic_message, and whether it is in General topic vs a named topic.

Issue tracker: https://github.com/openclaw/openclaw/issues 🦞

lunar ibex May 11, 2026, 10:36 PM

Which version did the fix telegram topic bottleneck land in? I want to install a specific version rather than latest. Hostinger is only pushing 4.21 I think.

waxen nightBOT May 11, 2026, 10:37 PM

It first lands in 2026.5.10-beta.1.

It is not in 2026.4.27, and it’s also not in current stable latest from npm (2026.5.7 when I checked). The npm beta tag is currently 2026.5.10-beta.5, which includes it.

Install a specific published version with:

pnpm add -g openclaw@2026.5.10-beta.5
openclaw gateway restart
openclaw --version

If you want the earliest exact one:

pnpm add -g openclaw@2026.5.10-beta.1

But I’d pick 2026.5.10-beta.5 over beta.1 unless you have a reason to pin the first beta. Hostinger’s 4.21 is too old for this fix.

lunar ibex May 11, 2026, 11:15 PM

beta.5 fixed Telegram group inbound — but Anthropic model_call stream handling is broken
Upgrade path: 2026.4.27 → 2026.5.10-beta.5
Fixed: Telegram group delivery is back. Inbound messages route correctly to all agents — [telegram] Inbound message telegram:group:... lines fire cleanly for every bot.
Broken (or newly exposed): Anthropic model calls stall at ~120s and surface_error via failover.
[diagnostic] stalled session: age=127s ... activeWorkKind=model_call lastProgress=model_call:started
[agent/embedded] Profile anthropic:default timed out. Trying next account...
[agent/embedded] [llm-idle-timeout] anthropic/claude-sonnet-4-6 produced no reply before the idle watchdog
[agent/embedded] embedded run failover decision: ... decision=surface_error reason=timeout from=anthropic/claude-haiku-4-5
Pattern: inbound message arrives → agent enters processing/model_call → no streamed reply → 120s idle watchdog → failover to next profile → also times out → surface error. The bot shows "typing" the entire time, then goes silent.
Confirmed it's not API-side: Direct curl -N with stream:true to claude-sonnet-4-5, from the same VPS, using the exact key out of auth-profiles.json, returns a complete streamed response in under a second. API, key, network, and model are all healthy. The hang is somewhere in beta.5's stream handling.
Intermittent, not total — some calls eventually complete after retries (Atlas eventually responded), others fail outright.
Schema note: auth profile location moved to per-agent in beta.5 — /data/.openclaw/agents/<name>/agent/auth-profiles.json. Correctly populated on my end.
Environment: Hostinger VPS, Ubuntu 24.04, ~10 agents active, container openclaw-64d3-openclaw-1.
Anyone else on beta.5 seeing model_call idle timeouts against Anthropic? Did the stream client change between 2026.4.27 and 2026.5.10-beta.5?

waxen nightBOT May 11, 2026, 11:16 PM

Yep, this is very likely a beta regression / newly exposed watchdog path. I checked the diff between 2026.4.27 and 2026.5.10-beta.5: there were stream/idle-timeout changes in that window, notably:

fix(agents): enforce idle timeout during stream setup
fix(agents): abort timed out stream setup
fix(agents): cap provider setup timeout

So the answer to “did stream client handling change?” is yes — not necessarily Anthropic-specific client code, but the embedded runner’s model stream setup/idle watchdog changed. Your symptom (model_call:started then exactly ~120s silence) lines up with that code path uncomfortably well.

Two useful next tests/workarounds:

Disable streaming for the affected Anthropic models to see if non-streaming calls complete:

openclaw config set agents.defaults.models '{
  "anthropic/claude-sonnet-4-6": { "streaming": false },
  "anthropic/claude-haiku-4-5": { "streaming": false }
}' --strict-json --merge

openclaw gateway restart

If that fixes it, that’s strong evidence the beta stream wrapper is the culprit.

Capture targeted logs for an issue:

openclaw config set logging.level debug

Then, in the container/service env if possible:

OPENCLAW_DEBUG_MODEL_TRANSPORT=1
OPENCLAW_DEBUG_SSE=events

Avoid OPENCLAW_DEBUG_MODEL_PAYLOAD=full-redacted unless you’re comfortable reviewing/redacting prompts before sharing.

Given you’ve already proven curl streaming works from the same VPS/key, I’d file this as a GitHub issue with the version jump and those log lines: https://github.com/openclaw/openclaw/issues

If non-streaming works, include that result too — it narrows this down a lot. 🦞

lunar ibex May 11, 2026, 11:34 PM

Update 2: Both groups have is_forum: True confirmed via getChat API. Back on 4.27 — both Atlas and CASH groups broken (as expected, fix not present).

One CASH group response came through briefly after rollback — likely a queued response from beta.5 processing, not a real fix.

Streaming disable didn't help on beta.5. Config applied: agents.defaults.models: {anthropic/claude-sonnet-4-6: {streaming: false}, anthropic/claude-haiku-4-5: {streaming: false}} — groups still no response after clean restart.

Exact stall pattern on beta.5:

stalled session: state=processing age=127s reason=active_work_without_progress
activeWorkKind=model_call lastProgress=model_call:started lastProgressAge=127s
embedded run failover decision: decision=surface_error reason=timeout

Is there a config to raise or disable the model call idle watchdog timeout? Or another workaround for the stream setup regression in beta.5?

waxen nightBOT May 11, 2026, 11:34 PM

Good update — and yes, there’s a better workaround than fighting beta.5.

I checked the tag ancestry:

2026.5.10-beta.1 / .2 / .3 include fix telegram topic bottleneck
2026.5.10-beta.4 / .5 additionally include the new stream setup idle-timeout changes

So try 2026.5.10-beta.3. It should have the Telegram forum/topic fix without the beta.5 stream watchdog regression:

pnpm add -g openclaw@2026.5.10-beta.3
openclaw gateway restart
openclaw --version

On the config question: in beta.5, I don’t see a clean config knob to disable that model-call idle watchdog for normal cloud Anthropic chat runs. models.providers.anthropic.timeoutSeconds exists, but beta.5’s resolver caps cloud-provider idle timeout back to the default 120s path, so it likely won’t help for this exact failure.