0.7.8-beta.6: all bots go silent after Ready event (no GUILD_CREATE, no MESSAGE_CREATE, no heartbeats)

[s88885301-design]

Summary

After upgrading from 0.7.7 to 0.7.8-beta.6, every Discord bot connects successfully (discord bot connected), emits the Ready event, and then falls completely silent. No further gateway events are received — no GUILD_CREATE, no MESSAGE_CREATE, and no shard heartbeat log lines.

Rolling back to 0.7.7 immediately restores normal operation.

Environment

• Version: openab-0.7.8-beta.6 (clean upstream tag, no local patches)
• Build: cargo build --release on Linux x86_64, Rust stable
• Deployment: 8 agent services on a single VPS, each binding its own Discord bot token (codex-acp + claude-agent-acp ACP backends)
• Discord intents: GUILD_MESSAGES | MESSAGE_CONTENT | GUILDS (default)

Reproduction

1. Build 0.7.8-beta.6 release binary from tag.
2. Deploy via systemd drop-in to a single service (isolated canary) pointing to the new binary.
3. Start service. Observe logs for 10 minutes.

Observed

Journal for the 10-minute window contains only 6 lines total:

```
INFO openab: config loaded agent_cmd=codex-acp pool_max=5 discord=true slack=false reactions=true
INFO openab: starting discord adapter channels=11 users=0 trusted_bots=7 allow_bot_messages=Mentions allow_user_messages=Mentions
INFO openab: discord bot running
INFO start:start_connection{start_shard=0 end_shard=0 total_shards=1}:initialize:boot{shard_info=[ShardId(0), ShardId(1)]}: serenity::gateway::bridge::shard_manager: Telling shard queuer to start shard 0
INFO run: serenity::gateway::bridge::shard_runner: [ShardRunner ShardInfo { id: ShardId(0), total: 1 }] Running
INFO openab::discord: discord bot connected user=
```

After the final discord bot connected, the process stays alive but emits zero subsequent log lines — no GUILD_CREATE for any of the server's guilds, no heartbeat ACK, no MESSAGE_CREATE even when explicit @-mentions target the bot in allowed channels.

Expected on 0.7.7 in the same environment: GUILD_CREATE within seconds, subsequent MESSAGE_CREATE as users post, periodic heartbeat activity.

Isolation

• Tested with zero local patches (direct cargo build --release from openab-0.7.8-beta.6 tag).
• Same bot token, same config.toml, same Discord intents as 0.7.7 deployment.
• No crashes, no OOM, no panic — process stays alive, just silent.
• Reproduced across all 8 service instances (identical symptom).
• Rollback to 0.7.7 binary with identical config → gateway events resume within seconds.

Suspected area

src/adapter.rs was rewritten between 0.7.7 and 0.7.8-beta.2 (#429) — the handle_message path was wrapped in tokio::spawn and the streaming-edit model was overhauled with use_streaming() gating. src/adapter.rs was not touched between beta.6 and beta.7, so 0.7.8-beta.7 likely shows the same behavior (haven't verified yet — will report back after building beta.7).

Worth investigating whether something in the new adapter flow or shard runner interaction is preventing serenity from delivering events after Ready. Could also be a subtle deadlock between the watch channel used for streaming and the spawned handle_message tasks.

Impact

Every multi-bot deployment that upgrades past 0.7.8-beta.2 is likely affected. Staying on 0.7.7 for the time being.

Happy to run diagnostics / patches against my environment to help isolate further.

[github-actions]

Thanks for the report! It looks like this issue was created without a template and is missing some required fields. Please add one of the following labels: bug, feature, documentation, or guidance, then edit this issue to include the matching template fields — the incomplete label will be removed automatically.

[s88885301-design]

Update: verified 0.7.8-beta.7 is still affected

Built and canaried openab-0.7.8-beta.7 in the same environment today (clean upstream tag, no local patches). Same silence reproduction — 10-minute observation window, 6 log lines total, stops at discord bot connected:

INFO openab: config loaded agent_cmd=codex-acp pool_max=5 discord=true slack=false reactions=true
INFO openab: starting discord adapter channels=11 users=0 trusted_bots=7 allow_bot_messages=Mentions allow_user_messages=Mentions
INFO openab: discord bot running
INFO start:start_connection: serenity::gateway::bridge::shard_manager: Telling shard queuer to start shard 0
INFO run: serenity::gateway::bridge::shard_runner: [ShardRunner ShardInfo { id: ShardId(0), total: 1 }] Running
INFO openab::discord: discord bot connected user=<REDACTED>

No GUILD_CREATE, no MESSAGE_CREATE, no heartbeat ACK — process alive but silent.

This matches the prediction: beta.6 → beta.7 diff only touches src/discord.rs / src/config.rs / src/main.rs / docs for the new multibot-mentions + turn-limits features. src/adapter.rs (where the handle_message path was wrapped in tokio::spawn and streaming logic was overhauled via #429) was not touched between those releases, so the regression carries through.

Likely first affected release: 0.7.8-beta.2 (the #429 adapter rewrite). Haven't built beta.2/.3/.4/.5 to confirm the exact first-affected tag — let me know if bisecting would help narrow it.

[chaodu-agent]

Thanks for the detailed report @s88885301-design.

I've reviewed the diff between v0.7.7 and v0.7.8-beta.6. The code changes (adapter.rs, discord.rs, pool.rs) are all inside the message handler path — they shouldn't affect event dispatch at the gateway/shard level. The ready handler, intents, serenity version, and tokio version are all identical between the two tags.

The symptom (zero events after Ready, including no GUILD_CREATE) points to something blocking at the serenity shard runner level, not in our handler code.

Could you help narrow this down with:

1. RUST_LOG=serenity=debug,openab=debug — run for ~2 minutes and share the full log. This will show gateway heartbeats, dispatch events, and any errors serenity swallows silently.

2. Confirm the binary hash — sha256sum of the binary you're running, to rule out stale build artifacts from incremental compilation. A cargo clean && cargo build --release from the tag would be the safest test.

3. Single-bot isolation — does the issue reproduce with only 1 service running (not all 8)? 8 bots on one VPS hitting Discord's gateway simultaneously could trigger identify rate limits that serenity doesn't surface in default logs.

4. Have you tried 0.7.8-beta.7? — you mentioned you haven't verified yet. The diff between beta.6 and beta.7 doesn't touch adapter/discord/pool, but worth confirming.

My current hypothesis is either a stale build artifact or a gateway-level issue (identify rate limit with 8 concurrent connections). The code path that changed (tokio::spawn for handle_message, pool refactor) only executes after a MESSAGE_CREATE is received — it can't prevent GUILD_CREATE from arriving.