feat(telegram): inbound reaction routing behind TELEGRAM_INBOUND_REACTIONS env toggle

[giwaov]

Summary

Telegram reactions (👍 ✅ 👎 ❌) were silently ignored. This adds opt-in routing of reactions as synthetic messages.

• Register MessageReactionHandler when TELEGRAM_INBOUND_REACTIONS=1; wrapped in try/except for library compatibility
• Allowlisted emoji translated to MessageEvent text (👍 → "👍", etc.)
• Bounded LRU cache (OrderedDict, max 512 entries, 1 h TTL) correlates bot message IDs to originating chat/thread context
• Cache is populated after each successful send() call

Test plan

• With TELEGRAM_INBOUND_REACTIONS=1: react with 👍 → agent receives "👍" message in correct conversation
• Non-allowlisted emoji → ignored
• Without env var set → reaction handler not registered, no change in behaviour
• Cache eviction after 1 h or when 512-entry limit is reached

Fixes #13942

[RichardAtCT]

Hey @giwaov — thanks for picking up #13942, appreciate it.

A few gaps I noticed that would be worth tightening before this merges:

1. The cache is never populated in practice. _cache_bot_message is only called when metadata contains a _source_event key, but grep -r _source_event against main returns zero hits — nothing in the repo ever sets it. Net effect with the PR as-is: the reaction cache stays empty, _handle_message_reaction always takes the "best-effort minimal source" branch, and the originating session/thread context is lost on every inbound reaction. Verified locally against main.

2. Only 1 of 10 bot-authored send paths is hooked. send() is patched, but send_exec_approval, send_model_picker, send_update_prompt, send_photo, send_video, send_voice, send_document, send_animation, and send_image all bypass the cache even if (1) were fixed. Approval prompts are arguably the highest-value target for this feature and would go uncorrelated.

3. reaction:removed events never fire. The handler only diffs new_reaction, so if a user adds 👍 and then un-taps it, the agent sees nothing. Feishu's inbound-reaction implementation in gateway/platforms/feishu.py emits both reaction:added:EMOJI and reaction:removed:EMOJI — worth mirroring for consistency.

4. Synthetic text format diverges from precedent. Feishu (merged) emits reaction:added:EMOJI; this PR emits [reaction: EMOJI]. Cross-platform agent-side handling is easier if they match.

5. No tests. Test plan is listed but unchecked, and the diff only touches telegram.py. tests/gateway/test_telegram_reactions.py has an established outbound-reaction test pattern that extends cleanly to inbound.

---

I have an alternative implementation sitting on a fork that covers all of the above — populates the cache from all 10 send paths with kind tags, emits add+remove deltas, matches the Feishu text format, adds a telegram.inbound_reactions YAML bridge alongside the existing telegram.reactions bridge, ships 14 new unit tests (all passing under scripts/run_tests.sh), and updates the Telegram user guide + env-var reference. Clean diff, +547/-1 across 5 files: RichardAtCT#1

Happy to either:

• (a) Open it as an upstream PR so maintainers can compare side-by-side, or
• (b) Cherry-pick specific fixes onto your branch as review commits here, whichever you and the maintainers prefer.

Whatever lands the cleanest implementation for the repo works for me — flagging the issues upfront so #13942 actually gets solved rather than half-solved.

[giwaov]

Addressed the review and force-pushed an updated branch on top of current main.

This version now:

• caches all bot-authored outbound send paths needed for inbound reaction routing
• routes both reaction:added:EMOJI and reaction:removed:EMOJI
• drops the dead _source_event dependency
• matches the Feishu-style synthetic text format
• adds the inbound-reaction config bridge, docs, and targeted tests

Validation run locally:

• python -m pytest tests/gateway/test_telegram_reactions.py -q --maxfail=5 -o addopts="-m 'not integration' -n 0 --basetemp=c:/Users/DELL/aibtc-godmode/.pytest_tmp_hermes"

Thanks for the detailed review and for pointing to the more complete approach.

[teknium1]

Thanks for incorporating the prior review's cache, add/remove-delta, docs, and test coverage. The feature is still needed: current main requests Update.ALL_TYPES at plugins/platforms/telegram/adapter.py:1989-1993, but its registrations at :3173-3190 do not include a reaction handler.

Problems

• This branch targets the legacy gateway/platforms/telegram.py; current main moved Telegram to plugins/platforms/telegram/adapter.py in 5600105478ffde29d7566b45421b100eaa29c4ef, including platform-specific YAML translation. The implementation and config bridge need a plugin-surface port.
• gateway/platforms/telegram.py:3261 accepts a cache entry without checking its TTL. Expiry runs only on a later insert (:3220-3226), so an otherwise idle adapter can route a stale reaction.
• website/docs/user-guide/messaging/telegram.md:565 promises a 👍/✅ acts as yes, while the handler emits reaction:added:<emoji> events (gateway/platforms/telegram.py:3312).

Suggested changes

• Port the feature to the plugin adapter/config bridge, expire entries at lookup, and add the idle-after-TTL test.
• Describe the synthetic event behavior without guaranteeing yes-equivalence.

Automated hermes-sweeper review.

[teknium1]

This lookup does not enforce the TTL. Entries are pruned only by a later _remember_bot_message() insert, so an idle adapter can route a reaction after the advertised expiry. Validate/delete the timestamp under this lock and add a no-later-send expiry test.

[teknium1]

The handler emits reaction:added:<emoji> / reaction:removed:<emoji>, not yes; please describe this as a synthetic reaction event rather than guaranteeing equivalent confirmation semantics.