mirror of
https://github.com/NousResearch/hermes-agent.git
synced 2026-07-09 13:21:42 +00:00
a0a3c716fc
Post-#48648, oversized mid-stream edits truncate to a 4096-char preview instead of splitting. But when rich messages raise the consumer's overflow budget to 32k, the consumer keeps accumulating past 4096 and keeps issuing progressive edits every edit_interval — each one truncating to the SAME preview text. Telegram counts every one of those no-op requests against the flood budget: a long streamed reply fires ~1 identical edit per 0.8s for the rest of the stream, trips flood control (200s+ penalties), and the final delivery hangs behind inline flood sleeps. Users see the bot stuck 'streaming' and the chat unresponsive. Fix at the chokepoint: track the last truncated preview per (chat_id, message_id) and skip the API call when the new truncation is identical. Previews still update when the visible prefix actually changes (e.g. chunk-count marker 1/2 → 1/3). State clears on finalize and when content shrinks back under the cap, so dedup can never mask a real edit. Live repro: 19,956-char streamed reply, transport=edit, rich available — 4x flood-control hits within ~700ms, 250s penalties, hung final delivery. E2E harness on the same stream: 14 edit calls on main vs 7 with the fix (the delta is pure no-op duplicates; scales with stream length). |
||
|---|---|---|
| .. | ||
| dingtalk | ||
| discord | ||
| feishu | ||
| google_chat | ||
| homeassistant | ||
| irc | ||
| line | ||
| matrix | ||
| mattermost | ||
| ntfy | ||
| photon | ||
| raft | ||
| simplex | ||
| slack | ||
| sms | ||
| teams | ||
| telegram | ||
| wecom | ||