NousResearch/hermes-agent

Telegram progress message coalescing and edit reliability

Cluster 9136 · gateway. Data as of 2026-10-26 12:29 UTC

2 open items. Fix merged in #28484 on 19 May 2026. Check it covers your case.

open issue

open PR

items grouped

Known?: Yes. 7 related items grouped here, 2 issues already closed.
Fix event: A fix was merged to main in PR #28484. Check it covers your case. No release data is tracked.
Tracker: The maintainers' tracker marks this unresolved. That is separate from the fix event.
Still open: 1 issue and 1 PR.

Next step: read #28484, then check whether your report is the one still open.

Read #28484 Pick up a Lab task

These issues and PRs address bugs where Telegram tool-progress messages stop being edited in place and instead spawn separate messages, particularly after flood control responses or transient network errors. Work covers preserving edit capability across error conditions and recovering coalescing behavior.

Open issues1

Issue#9136[Bug]: Progress messages stop coalescing after approval — each trajectory becomes a separate message

Open PRs1

PR#9345fix(gateway): recover progress coalescing after stale edits

Fixes on record

Merged to main. A stamp counts the issues a fix is linked to.

#28484 fix(gateway): keep tool-progress edits alive after Telegram flood control (closes #25188)

merged to main

files: gateway/run.py, scripts/release.py

Show the diff

gateway/run.py

@@ -15463,14 +15463,15 @@ async def _roll_progress_overflow_if_needed() -> bool:
                         if not result.success:
                             _err = (getattr(result, "error", "") or "").lower()
                             if "flood" in _err or "retry after" in _err:
-                                # Flood control hit — disable further edits,
-                                # switch to sending new messages only for
-                                # important updates.  Don't block 23s.
+                                # Flood control hit — backoff but keep editing.
+                                # Only disable edits for non-recoverable errors.
                                 logger.info(
-                                    "[%s] Progress edits disabled due to flood control",
+                                    "[%s] Progress edit flood control, backing off",
                                     adapter.name,
                                 )
-                            can_edit = False
+                                _last_edit_ts = time.monotonic()
+                            else:
+                                can_edit = False
                             _flood_result = await adapter.send(
                                 chat_id=source.chat_id,
                                 content=msg,

scripts/release.py

@@ -166,7 +166,7 @@
     "[redacted:email]": "Junass1",
     "[redacted:email]": "Bartok9",
     "[email protected]": "Bartok9",
-    "[email protected]": "pepelax",  # PR #25419 salvage (send_message TELEGRAM_PROXY)
+    "[redacted:email]": "erhnysr",  # PR #25198 salvage (tool-progress flood-control)
     "[redacted:email]": "hllqkb",
     "[email protected]": "Bongulielmi",
     "[redacted:email]": "JTroyerOvermatch",

2 PRs closed without merging

From the close comments: merged via another change 2

#25198 fix(gateway): keep tool-progress edits alive after Telegram flood control · merged via another change → #28484
#27839 fix(telegram): preserve can_edit after transient network errors in progress edits (#27828) · merged via another change

Closed issues · 2

Closed#25188[Bug]: Telegram flood-control fallback stops coalescing tool progress and starts sending new messages
Closed#27828Telegram tool-progress edits permanently fall back to separate messages after transient edit_message network error

How this cluster was grouped

Link evidence (partly structural links): some members are connected by structural evidence (shared changed files, or a closing/superseded reference); the rest are joined by an automated relevance judgement over their text.
Members outside that structural core may belong to a different underlying problem.
Pairwise link density 0.22: the share of item pairs that carry a link, counting a structural link in full and a relevance-only link at 0.36. 1.00 means every pair is linked.

Pick up a Lab task

Check whether a fix covers the open issues here, with your own agent. Bring back evidence for maintainers.

Open the Lab

At a glance

Subsystem: gateway
Merged PRs: #28484
Closed issues: 2
Attempts: 2 PRs closed without merging
Fix link checked: 19 May 2026

For your agent

The same facts, typed.

cluster/9136.json
cluster/9136.md