bug(discord): streamed responses post empty MESSAGE_CREATE then MESSAGE_UPDATE patches — receiver bots in multi-bot threads silently miss them

[brettchien]

Description

When Discord streaming is enabled, openab posts a placeholder … via MESSAGE_CREATE and patches the real content in through repeated MESSAGE_UPDATE (~1500ms interval, see adapter.rs:485-522). Receiver bots' EventHandler::message() fires on MESSAGE_CREATE only — they see the empty placeholder, never the mention/content patched in later. There is no message_update() handler in discord.rs (handler trait at src/discord.rs:323+).

Result: in multi-bot threads, a streaming sender's mention silently fails to trigger receiver bots. Per-thread multibot streaming gating (#534 / #535) is supposed to mitigate this, but has gaps:

• Cold-start threads where multibot_threads cache hasn't seen the other bots yet
• Sender's first response in a thread before detection populates the cache
• Any path where use_streaming() returns true while ≥2 bots are actually present

Steps to Reproduce

1. Create a Discord thread with three bots A, B, C, all running openab.
2. Bot A sends a mention-bearing message @B @C <task> through normal streaming pipeline (no curl, no special config).
3. Bot A's content arrives as MESSAGE_CREATE { content: "…" } then a sequence of MESSAGE_UPDATE events filling in <@B> <@C> <task>.
4. Observe: B and C never dispatch — their brokers logged the MESSAGE_CREATE with empty/placeholder content and treated it as not-for-me; the subsequent MESSAGE_UPDATE events are ignored.

Expected Behavior

Two complementary fixes (defense in depth):

(a) Proactively disable streaming in any multi-bot-capable thread. Don't wait for multibot_threads cache to observe the other bots — make use_streaming() return false for any thread whose channel config allows bot-to-bot messages, or detect bot members at thread-creation time. Closes the cold-start / race window where streaming starts before detection populates.

(b) Add a message_update() handler that re-evaluates dispatch when an empty/placeholder MESSAGE_CREATE gets patched with mention content. Treats the broker's empty placeholder + later edit as a single logical message-arrival event from the receiver's perspective. Even if (a) misses a case, this is a safety net.

Either fix alone leaves the other gap open; together they close both the proactive and reactive paths.

Environment

• openab 0.8.4 (HEAD of feat/openab-agent-mcp-resilience, base main)
• Platform: Discord
• Config: allow_bot_messages = \"mentions\", multi-bot deployment

Logs / Evidence

Real incident 2026-06-03 — cron-driven multi-bot fact-check workflow in thread 1511750862865956957 (3 bots: Jellyfish orchestrator, Kirin, Mira).

• Jellyfish's streamed page-request messages mentioning <@Kirin> <@Mira> did not appear in Mira broker's dispatch log during 16:28:13–16:32:04.
• Discrete non-streamed short messages from the same thread (👍) were dispatched in the same window.
• Confirmed by inspecting Mira broker logs against Discord message timeline.

Workaround currently in use: callers post triggering messages via raw Discord API POST /channels/<id>/messages so MESSAGE_CREATE is delivered with full content in one event. Works reliably but pushes the responsibility into every multi-bot runbook author.

Related

• feat(discord): per-thread streaming decision based on multibot detection #534 / feat(discord,slack): per-thread streaming based on multibot detection #535 — per-thread multibot streaming detection (necessary, but doesn't cover cold-start / race window)
• bug(slack): streaming not disabled in multi-bot threads — wrong cache key in handle_message #556 / fix(slack): use thread_ts key for multibot_threads cache lookup in handle_message #560 — Slack analogue (multibot_threads cache-key bug)
• feat: per-thread serialization, conditional streaming, and multi-bot fixes #420 — original multibot fixes

[CHC-Agent]

Issue at a Glance

Sender Bot (streaming)          Discord Gateway         Receiver Bots
       │                              │                       │
       ├── MESSAGE_CREATE {"…"} ─────►├──────────────────────►│ message() fires
       │                              │                       │ → content is "…", no @mention → skip
       │                              │                       │
       ├── MESSAGE_UPDATE {@B task} ──►│─────────────────────►│ ⚠️ NO message_update() handler
       │                              │                       │ → event silently dropped
       │                              │                       │
       │   multibot_threads cache     │                       │
       │   NOT YET populated on       │                       │
       │   cold-start threads         │                       │
       └──────────────────────────────┘                       │
           use_streaming(false)=true                           │
           ↑ race: streams before                             │
             detection populates cache                        │

Hi @brettchien,

Confirmed — source code at src/discord.rs:323+ implements only EventHandler::message() with no message_update() handler. The use_streaming() function (line 135) returns true whenever other_bot_present is false, which means cold-start threads (before multibot_threads cache is populated) will stream even when other bots are present.

Two gaps verified from code:

1. Cold-start race: multibot_threads is only populated when a bot message is received (line 331), so the very first response in a thread streams unconditionally.
2. No reactive path: MESSAGE_UPDATE events carrying the patched-in mentions are never processed — the event handler trait impl has no message_update method.

Related:

• feat(discord): per-thread streaming decision based on multibot detection #534 — feat: per-thread streaming decision based on multibot detection (CLOSED)
• PR feat(discord,slack): per-thread streaming based on multibot detection #535 by @chaodu-agent — feat(discord,slack): per-thread streaming based on multibot detection (MERGED, covers the detection but not cold-start)
• PR feat(discord): handle streaming bot @mentions via message_update #827 by @jasonni — feat(discord): handle streaming bot @mentions via message_update (CLOSED, not merged — implements the reactive message_update() handler described in this issue)
• PR feat: per-thread serialization, conditional streaming, and multi-bot fixes #420 by @dogzzdogzz — feat: per-thread serialization, conditional streaming, and multi-bot fixes (MERGED, original multibot fixes)
• fix(slack): use thread_ts key for multibot_threads cache lookup in handle_message #560 by @antigenius0910 — fix(slack): multibot_threads cache-key bug (MERGED)

A PR to fix this is welcome — feel free to open one if you are interested.

[github-actions]

This issue has been open for more than 14 days with no linked pull request, so it is being closed as not planned.

If this is still needed, please open a new issue with updated context and reference this closed issue instead of reopening it. A linked PR is the strongest signal that the work matters.