#telegram messages in groups with topics not getting replies

48 messages · Page 1 of 1 (latest)

buoyant ether
#

i tried diagnosing by chatting to the bot in DM and this is what it said:

Given your timeline, this does look like an OpenClaw regression window after 2026.4.8.

What I can confirm:

• Your Telegram gating/approval config has been basically stable for weeks.
• So the behavior shift is likely from runtime changes, not you changing settings.
• The symptom split still fits:
  • some turns get dropped as no-mention
  • others pass gate (react + typing) and then die before final send```

can you run your own investigation based on what others have said, the changes and and any github issues?

also just now i asked a big question (single message) and got:

```⚠️ Context limit exceeded. I've reset our conversation to start fresh - please try again.

To prevent this, increase your compaction buffer by setting agents.defaults.compaction.reserveTokensFloor to 20000 or higher in your config.```

but thing is i also got this two messages ago so why did that happen again?
deep runeBOT
rancid crystalBOT
#

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

deep runeBOT
hidden quailBOT
#

Let me dig into the docs + current code/history a bit, then I’ll come back with a concrete read on both the Telegram reply regression and why compaction hit you twice.

#

yeah, I dug through the recent code/history and GitHub stuff. Short version, this really does smell like a real regression cluster around Telegram topics + session/compaction handling, not just you misconfiguring something.

Most relevant things I found:

  • 2026.4.11 includes fix: canonicalize topic session transcript fallback (#64869).
    The fix description is basically: a Telegram topic session could bounce between
    session.jsonl and session-topic-<id>.jsonl for the same logical conversation.
    That is very close to your symptom set, especially the weird “I just reset, why did it blow up again?” behavior.

  • 2026.4.11 also includes fix: preserve Telegram topic routing for exec completions (#64580).
    So there was definitely active work on topic-scoped async reply routing right after 2026.4.8.

  • There’s a fresh issue, #64983, reporting dropped Telegram replies after context overflow/tool-loop termination on 2026.4.10.
    That lines up with your “react + typing, then no final send” pattern.

  • Older issues also show this area has been fragile before:

    • #14032 Telegram topic/thread replies broken
#
  • #19883 topic messages skipped as no-mention
    • #29820 topic messages not triggering inbound processing

So my current read is:

  1. The “no-mention” drops are plausibly a real Telegram-topic mention-gating bug/regression, not just your config.
  2. The “react + typing, then dies” cases fit the newer overflow / tool-loop / async-delivery failures people are reporting.
  3. The repeated context reset can absolutely happen again if the reset did not actually escape the bad transcript/session path, or if the next turn immediately reloads the wrong topic transcript.
    That 4.11 topic transcript fix is the strongest clue there.

Why it happened again two messages later:

  • that warning is a per-turn hard reset, not a permanent repair.
  • if the underlying problem is still there, the next turn can trip it again.
  • in Telegram topics, the most suspicious cause is that transcript/session routing bug fixed in 2026.4.11.

So my recommendation is:

#
  1. Paste openclaw --version
  2. If you are below 2026.4.11, I would update first before chasing config ghosts.
  3. If your agents.defaults.compaction.reserveTokensFloor is below 20000, bump it.
    I’d probably use 24000 now.
  4. If it still repros on 2026.4.11, that’s GitHub-issue territory, with logs around one failing turn.

Docs:

If you want, send:

  • openclaw --version
  • your Telegram groups/topics config block
  • 30 to 50 lines from openclaw logs --follow around one failed topic message

and I’ll help narrow whether you’re hitting mention gating, topic transcript drift, or overflow-after-tool-loop.

buoyant ether
#

give me the links to the github issues you mentioned

also, i am currently on 2026.4.11

hidden quailBOT
#

yep, these are the ones I meant:

And the two fixes I mentioned from recent changes:

#

includes the topic/session fixes

Since you’re already on 2026.4.11, that makes this more interesting, honestly. It means you’re probably not just hitting the already-fixed transcript-routing bug in its original form, or you’re hitting a related edge case that 4.11 didn’t fully close.

If you want, next I can help you turn this into a tight repro + likely new GitHub issue instead of just guessing.

buoyant ether
#

yeah sure lets do that

hidden quailBOT
#

nice. I’d split this into 2 issues, because the evidence points to 2 different failure paths.

1) Topic message gets skipped as no-mention

Suggested title
[Bug]: Telegram forum/topic messages intermittently skip mention detection on 2026.4.11

Draft

## Summary
On OpenClaw 2026.4.11, Telegram group/topic messages that should trigger the bot are intermittently skipped as `no-mention`.

## Environment
- OpenClaw: 2026.4.11
- Channel: Telegram
- Context: group with topics enabled
- Direct DM behavior: works / does not work
# 
- Topic behavior: fails intermittently

## Expected
A topic message that mentions the bot, or is otherwise allowed by the configured topic/group policy, should trigger normal processing and reply.

## Actual
Some topic messages are skipped as `no-mention` even though the gating/config has been stable and the same setup worked before.

## Repro
1. Send a message in a Telegram topic that should pass gating.
2. Observe no reply.
3. Logs show skip reason `no-mention`.

## Notes
- This appears to be a regression window after 2026.4.8.
# 
- Related historical issues:
  - #19883
  - #29820

2) Topic message passes gate, shows ack/typing, then no final reply, sometimes followed by repeated hard context resets

Suggested title
[Bug]: Telegram topic turns can ack + type but never send a final reply on 2026.4.11, with repeated "Context limit exceeded" resets

Draft

## Summary
On OpenClaw 2026.4.11, some Telegram topic messages pass gating, show acknowledgement/typing, and then never deliver a final reply. In the same period, the session can emit:
"⚠️ Context limit exceeded. I've reset our conversation to start fresh - please try again."
This can happen again only a couple of messages later.
# 

## Environment
- OpenClaw: 2026.4.11
- Channel: Telegram
- Context: group with topics enabled
- Direct DM behavior: works / does not work

## Expected
Once a topic message passes gating and the bot starts typing, the user should either get:
- a normal final reply, or
- a clear fallback error reply

A hard reset should also not immediately recur on the next couple of turns unless the underlying state is still broken.

## Actual
# 
Observed split:
- some topic turns are dropped as `no-mention`
- others pass gate, show ack/typing, then die before final send
- repeated hard context reset message can reappear shortly after a previous reset

## Repro
1. Send a larger question in a Telegram topic.
2. Observe ack/typing.
3. No final reply arrives, or the run ends in repeated context reset behavior.

## Notes
- This still reproduces on 2026.4.11.
- Related recent context:
  - #64983
  - PR #64869
# 
  - PR #64580

Before filing, grab these

  • openclaw --version
  • your relevant channels.telegram.groups / topics config block
  • chat id and topic id
  • 30 to 80 log lines around one failure from openclaw logs --follow
  • whether DMs still work while topics fail

If you paste those here, I’ll tighten both drafts so they’re ready to post.

buoyant ether
#

direct dm works, only in group topics it doesnt but it does react, openclaw installed via coolify running on debian 25.04

it was working until 2026.4.7 or 2026.4.8

anything else i missed?

hidden quailBOT
#

yeah, that narrows it down a lot.

The big things you’ve already got, and should absolutely include, are:

  • Direct DM works
  • Only Telegram group topics fail
  • It still reacts / shows typing in topics
  • Regression window is around 2026.4.7 / 2026.4.8
  • You’re on 2026.4.11 now
  • Running via Coolify

That’s actually really good evidence, because it suggests:

  • not a total Telegram outage
  • not a total auth/setup failure
  • not just “bot never sees the message”
  • and for the react + typing cases, the failure is after ingress, later in routing/run/reply
#

The main things still worth adding

  1. Exact version string

    • openclaw --version
    • if possible, exact Docker/image tag from Coolify too

  2. Telegram bot state

    • bot is admin in the group
    • BotFather privacy mode is disabled
    • whether you re-added the bot after privacy changes

  3. Exact affected IDs

    • group chat id
    • one affected topic id
    • whether all topics fail or only some

  4. Relevant config block

    • channels.telegram.groupPolicy
#
  • channels.telegram.groups.<chatId>
    • topics
    • requireMention
    • any approvals/gating bits
  1. Two log snippets
    • one where it gets skipped as no-mention
    • one where it reacts / types but never sends a final reply
      This second one is the most valuable now.

One more useful sentence for the issue

Something like:

“This is not a general Telegram failure. Direct chats still work. The regression is specific to Telegram group topics. Some topic turns are misclassified as no-mention, while others clearly pass ingress (reaction + typing) but fail before final delivery.”

If you want, paste:

  • exact openclaw --version
#
  • the Telegram config block
  • one or two log snippets

and I’ll turn it into a cleaner final issue draft.

buoyant ether
#

OpenClaw 2026.4.11 (769908e)

telegram config was set to allow explictly two users, added to a group and works there and the group was split into topics. everything was working fine up to 2026.4.7 or 2026.4.8

and remember to include the relevant issues and send the final drafts

hidden quailBOT
#

yep, here are the final drafts. I’d still file them as 2 separate issues.

Draft 1: no-mention in Telegram topics

## Summary

On OpenClaw **2026.4.11 (769908e)**, Telegram **group topic** messages are intermittently skipped as `no-mention`, even though the same setup worked previously and direct DMs still work.

This looks like a regression window somewhere after **2026.4.7 / 2026.4.8**.

## Environment

- OpenClaw: **2026.4.11 (769908e)**
- Deployment: **Coolify** on Linux
- Channel: **Telegram**
# 
- Context: **group with topics enabled**
- Direct DM behavior: **works**
- Topic behavior: **fails intermittently**
- Access model: Telegram config explicitly allowlists **two users**

## Configuration context

- Telegram config was explicitly set to allow two users
- Bot works in direct chat
- Bot worked in the group before / around the earlier setup
- The group was later split into **topics**
- Everything was still working up to about **2026.4.7 or 2026.4.8**

## Expected behavior
# 
A message in a Telegram topic that should pass the configured gating rules should be processed normally and receive a reply.

## Actual behavior

Some topic messages are skipped with reason `no-mention`, even though:

- the setup was previously working
- DMs still work
- the regression appears version-related rather than config-related

## Reproduction outline

1. Use Telegram with a group that has topics enabled
2. Keep the existing allowlisted-user setup
3. Send a topic message that should pass gating
# 
4. Observe that some messages are skipped as `no-mention`

## Why this seems important

This does **not** look like a total Telegram failure:

- Direct DMs still work
- The regression is specific to **group topics**
- The behavior changed after a version window, not after a config rewrite

## Related issues / context

Historical topic-related regressions:

- #14032 <https://github.com/openclaw/openclaw/issues/14032>
# 
- #19883 <https://github.com/openclaw/openclaw/issues/19883>
- #29820 <https://github.com/openclaw/openclaw/issues/29820>

Recent related fixes in 2026.4.11:

- PR #64869 <https://github.com/openclaw/openclaw/pull/64869>
- PR #64580 <https://github.com/openclaw/openclaw/pull/64580>

Draft 2: reacts / types, then no final reply + repeated context reset

## Summary
# 

On OpenClaw **2026.4.11 (769908e)**, some Telegram **group topic** messages clearly pass ingress, because the bot reacts and shows typing, but **no final reply is delivered**.

In the same period, the session can also emit:

> ⚠️ Context limit exceeded. I've reset our conversation to start fresh - please try again.
>
> To prevent this, increase your compaction buffer by setting agents.defaults.compaction.reserveTokensFloor to 20000 or higher in your config.

Notably, this hard reset message can happen again only a couple of messages later, even after a previous reset.

## Environment

- OpenClaw: **2026.4.11 (769908e)**
- Deployment: **Coolify** on Linux
# 
- Channel: **Telegram**
- Context: **group with topics enabled**
- Direct DM behavior: **works**
- Topic behavior: **fails intermittently**
- Access model: Telegram config explicitly allowlists **two users**

## Configuration / timeline context

- Telegram setup had been stable
- Group/topic behavior worked up to about **2026.4.7 or 2026.4.8**
- Regression was noticed after that window
- This is topic-specific, not a global Telegram outage

## Expected behavior
# 
If a topic message passes ingress and the bot starts reacting / typing, the user should receive either:

- a normal final reply, or
- an explicit fallback error reply

A hard context reset also should not immediately recur on the next couple of turns unless the underlying session/topic state is still broken.

## Actual behavior

Observed split:

- some topic turns are skipped as `no-mention`
- other topic turns clearly pass ingress, because the bot reacts and shows typing
- those admitted turns can then die before final delivery
- repeated hard context reset warnings can reappear shortly after a prior reset
# 

## Why this seems important

This is **not** a general Telegram transport failure:

- direct DMs still work
- the issue is specific to **group topics**
- for the admitted turns, the failure happens **after ingress**, somewhere in routing, run execution, compaction, or final delivery

## Reproduction outline

1. Use Telegram in a group with topics enabled
2. Send a message in a topic
3. Observe that the bot reacts and/or shows typing
4. No final reply arrives
# 
5. In some cases, a repeated hard context reset warning appears

## Related issues / context

Closest recent related report:

- #64983 <https://github.com/openclaw/openclaw/issues/64983>

Historical topic-related context:

- #14032 <https://github.com/openclaw/openclaw/issues/14032>
- #19883 <https://github.com/openclaw/openclaw/issues/19883>
- #29820 <https://github.com/openclaw/openclaw/issues/29820>

Recent related fixes in 2026.4.11:
# 

- PR #64869 <https://github.com/openclaw/openclaw/pull/64869>
- PR #64580 <https://github.com/openclaw/openclaw/pull/64580>

These are solid enough to post now.

If you later grab logs, I’d add them as a follow-up comment rather than waiting.

buoyant ether
#

also, just now after running /compact, my first question after that still gave me a ```⚠️ Context limit exceeded. I've reset our conversation to start fresh - please try again.

To prevent this, increase your compaction buffer by setting agents.defaults.compaction.reserveTokensFloor to 20000 or higher in your config.```

hidden quailBOT
#

oof, that’s a really important clue.

If you ran /compact, and then the very next question still immediately hit the same hard reset, that makes this look a lot less like “you simply asked a big question” and a lot more like:

  • compaction is not actually recovering usable headroom
  • or the wrong topic/session transcript is still being replayed
  • or context-window accounting is off for that path

So yes, please add that to issue 2. I’d actually move it near the top.

Add this to the draft

Additional observation:
- I manually ran `/compact`
- The very first question after manual compaction still produced:
  "⚠️ Context limit exceeded. I've reset our conversation to start fresh - please try again."
# 
- So this does not look like a normal long-chat-only overflow. It looks like compaction either is not taking effect, is not reclaiming enough usable space, or the wrong topic/session state is still being replayed after compaction.

Why this matters

A manual /compact should usually buy you at least one normal follow-up turn.
If it doesn’t, that’s a much stronger bug signal.

One more related issue you may want to reference

At this point, if you only file one first, I’d file issue 2 first, because the /compact repro makes it much sharper.

buoyant ether
#

include both as one issue since these could be related

hidden quailBOT
#

yep, that’s reasonable. Here’s a single combined draft you can paste as one issue:

## Summary

On OpenClaw **2026.4.11 (769908e)**, Telegram **group topics** appear to have a regression that started sometime after **2026.4.7 / 2026.4.8**.

The behavior splits into two closely related symptom groups in the same environment:

1. Some topic messages are skipped as **`no-mention`**
2. Other topic messages clearly pass ingress, because the bot reacts and/or shows typing, but then **no final reply is delivered**

In the same period, the session can also emit repeated hard context reset warnings, including **immediately after manual `/compact`**.

Direct DMs still work. The issue seems specific to **Telegram group topics**.
# 
## Environment

- OpenClaw: **2026.4.11 (769908e)**
- Deployment: **Coolify** on Linux
- Channel: **Telegram**
- Context: **group with topics enabled**
- Direct DM behavior: **works**
- Group topic behavior: **fails intermittently**
- Access model: Telegram config explicitly allowlists **two users**

## Configuration / timeline context

- Telegram config has been stable
- The bot was added to a group and worked there
- The group was later split into **topics**
# 
- Everything was working fine up to around **2026.4.7 or 2026.4.8**
- The behavior change appears tied to a runtime/version window, not a deliberate config rewrite

## Expected behavior

For Telegram topic messages that should pass the configured gating rules:

- they should not be misclassified as `no-mention`
- if the bot reacts / shows typing, a final reply should be delivered
- manual `/compact` should reclaim enough headroom for at least the next normal turn
- hard context reset warnings should not recur immediately after reset/compaction unless the underlying session/topic state is still broken

## Actual behavior

Observed split:
# 

- some topic messages are skipped as **`no-mention`**
- other topic messages clearly pass ingress, because the bot reacts and/or shows typing
- those admitted turns can then die before final delivery
- repeated hard reset warnings can appear:

```text
⚠️ Context limit exceeded. I've reset our conversation to start fresh - please try again.

To prevent this, increase your compaction buffer by setting agents.defaults.compaction.reserveTokensFloor to 20000 or higher in your config.

Additional observation:

  • I manually ran /compact
# 
- the **very first question after manual compaction** still produced the same hard reset warning
- so this does not look like a normal "conversation just got too long" overflow
- it looks more like compaction is not taking effect, not reclaiming enough usable space, or the wrong topic/session state is still being replayed after compaction

## Why this seems important

This does **not** look like a general Telegram outage or auth/setup failure:

- direct DMs still work
- the issue is specific to **group topics**
- for the react + typing cases, the failure happens **after ingress**
- the timing lines up with a recent regression window

## Reproduction outline
# 
1. Use Telegram with a group that has topics enabled
2. Keep the existing allowlisted-user setup
3. Send messages into a topic
4. Observe one of two failure modes:
   - message gets skipped as `no-mention`
   - bot reacts / types, but never sends a final reply
5. In some cases, manual `/compact` still does not recover the session, and the next turn immediately hits the same hard reset warning

## Related issues / context

Historical topic-related issues:
- https://github.com/openclaw/openclaw/issues/14032
- https://github.com/openclaw/openclaw/issues/19883
- https://github.com/openclaw/openclaw/issues/29820
# 
Recent related issue:
- https://github.com/openclaw/openclaw/issues/64983

Related hard-reset context:
- https://github.com/openclaw/openclaw/issues/55366

Recent fixes that seem adjacent:
- https://github.com/openclaw/openclaw/pull/64869
- https://github.com/openclaw/openclaw/pull/64580

If you want, I can also do a shorter maintainer-style version after this, but this one is pretty solid already.

buoyant ether
#

ok another thing, this only happens when thinking/reasoning is set to high but just now it worked when it was at medium

hidden quailBOT
#

that’s probably the best clue yet.

If high thinking/reasoning breaks it, but medium works, that strongly suggests this is not just Telegram topics in general. It points more specifically at a reasoning/replay/compaction path that gets exercised at high and not at medium.

I’d add this near the top of the issue:

## Reasoning-level clue

This appears to be sensitive to reasoning level:

- **High** thinking/reasoning: reproduces the failure
- **Medium** thinking/reasoning: worked in the same setup

This makes the bug look less like a generic Telegram topic routing problem and more like a reasoning-specific replay/compaction/final-delivery issue that only shows up under higher reasoning settings.