Summary

• Problem: Since 2026.3.1, when sending messages to different Discord channel-bound agents on the same account, they are processed sequentially instead of in parallel. Agent B waits for Agent A's full reply before it begins processing.
• Why it matters: Users with 8+ channel-bound agents experience severe latency — every message blocks behind unrelated agents, effectively making the system single-threaded per Discord account.
• What changed: Replaced the single per-account messageQueue Promise chain in DiscordMessageListener with per-channel queues (Map<channelId, Promise>). Messages within the same channel remain serialized to preserve ordering, while messages to different channels proceed independently.
• What did NOT change: No changes to message routing, session resolution, command queue, or maxConcurrent behavior. No Discord API interaction changes.

Change Type (select all)

• Bug fix
• Feature
• Refactor
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes 2026.3.1 regression: channel-bound agents process messages sequentially instead of in parallel #31530

User-visible / Behavior Changes

• Channel-bound agents now process messages in parallel again (matching 2026.2.26 behavior)
• Same-channel messages remain serialized (ordering preserved)

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No

Repro + Verification

Environment

• OS: macOS Darwin 25.3.0 (arm64)
• Runtime: Node v22
• Integration/channel: Discord (8+ channel-bound agents)

Steps

1. Configure 8+ agents with individual Discord channel bindings on the same account
2. Send messages in rapid succession to 2+ different channels
3. Observe that agents now begin processing immediately (in parallel), not sequentially

Expected

Agent B starts processing its message while Agent A is still replying to its own.

Actual (before fix)

Agent B waits for Agent A to fully complete before beginning, even though they are on different channels.

Evidence

Root cause: DiscordMessageListener used a single messageQueue Promise chain per account. All incoming messages — regardless of channel — were serialized through this single chain. This created head-of-line blocking across unrelated channels.

Before (single queue):

private messageQueue: Promise<void> = Promise.resolve();

async handle(data, client) {
  this.messageQueue = this.messageQueue
    .catch(() => {})
    .then(() => this.handler(data, client));
  // All messages wait behind each other
}

After (per-channel queues):

private channelQueues = new Map<string, Promise<void>>();

async handle(data, client) {
  const channelId = data.channel_id;
  const prev = this.channelQueues.get(channelId) ?? Promise.resolve();
  const next = prev
    .catch(() => {})
    .then(() => this.handler(data, client));
  this.channelQueues.set(channelId, next);
  // Same channel serialized, different channels parallel
}

Tests: 4/4 pass — including a new test that verifies different channels run in parallel while same-channel messages remain serialized.

Human Verification (required)

• Verified scenarios: same-channel serialization, cross-channel parallelism, error handling, memory cleanup of completed queue entries
• Edge cases checked: thread channels (separate channel_id), DMs (separate channel_id), rapid bursts on same channel
• What I did not verify: Live gateway with 8+ agents (no Discord bot token available)

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No

Failure Recovery (if this breaks)

• How to disable/revert: Revert this single commit
• Files/config to restore: None
• Known bad symptoms: If per-channel queues cause issues, messages may interleave within a channel (would be detected by out-of-order replies)

Risks and Mitigations

• Risk: Higher concurrent model/IO load during traffic bursts (8+ channels processing simultaneously). Mitigation: The downstream command queue with maxConcurrent already gates actual agent execution; the change only affects the preflight/routing phase.
• Risk: Memory accumulation from per-channel Map entries. Mitigation: Completed queue entries are automatically cleaned up when no newer messages are pending for that channel.