openclaw - 💡(How to fix) Fix Bug: Telegram message_reaction updates consumed by gateway but never delivered as agent prompts (v2026.5.7)

Summary

After upgrading to v2026.5.7, Telegram reaction events (message_reaction updates) are silently dropped between the gateway's polling layer and the agent session. The gateway successfully consumes the updates (lastUpdateId advances), but no corresponding prompt.submitted event is ever generated. Reproduced under both reactionNotifications: "all" and reactionNotifications: "own".

Possibly a regression of #47126 (closed as fixed in v2026.4.22), or a new edge case not covered by that fix.

Environment

• openclaw 2026.5.7 (commit eeef486)
• macOS Darwin 25.4.0 (arm64)
• Node v24.14.0
• Channel: Telegram, polling mode
• getWebhookInfo reports message_reaction ∈ allowed_updates

Reproduction

1. channels.telegram.reactionNotifications: "all" (or "own" — same result)
2. User DMs the bot, bot replies
3. User adds an emoji reaction to the bot's reply
4. Observe:
   • ~/.openclaw/telegram/update-offset-default.json lastUpdateId advances → gateway consumed the update
   • No prompt.submitted event of form Telegram reaction added: <emoji> by <user> on msg <id> ever appears in any session trajectory (verified across all today's session JSONLs)

What I verified

• ✅ Bot token alive: getMe returns OK
• ✅ getWebhookInfo.allowed_updates includes message_reaction
• ✅ Gateway holds the Telegram getUpdates slot (409 Conflict when probing externally)
• ✅ Text and voice messages from the same user in the same DM do become prompt.submitted events normally — only reactions are silently dropped
• ✅ Updates are being consumed (offset advances by +N when user sends text + reacts, but only the text creates a prompt)
• ❌ Zero prompt.submitted events of reaction shape have ever been generated in any session today

Side issue (related but separate)

The default `channels.telegram.timeoutSeconds: 30` is too tight against grammY's 30s long-poll default. Every empty long-poll hits the local HTTP timeout exactly at 30s, producing endless:

``` [telegram] Polling stall detected (active getUpdates stuck for 30s); forcing restart. [telegram][diag] polling cycle finished reason=polling stall detected ... durationMs=30009 ... error=Network request for 'getUpdates' failed! ```

Bumping `timeoutSeconds` to 60 stopped the stall loop but did not recover reactions. Suggest the schema default be ≥ 35, or that grammY's long-poll be capped below `timeoutSeconds`.

Expected

A user reacting on a bot DM reply produces a `prompt.submitted` for the agent (`"Telegram reaction added: 👍 by <user> on msg <id>"`).

Actual

Update is consumed, offset advances, no prompt is ever generated.