Bug Report

Version: 2026.3.23 (ccfeecb)
OS: Linux 6.8.12-15-pve (x64)
Channel: msteams (bundled plugin)

Problem

When a message delivery to Teams fails (e.g., Bot Framework returns 502 or connection times out), the agent believes the message was sent successfully. The user never receives the message, and the agent continues as if delivery succeeded.

This leads to a frustrating pattern where:

1. User sends message
2. Agent processes it and generates a response
3. Response fails to deliver (silently)
4. User waits, sees nothing, sends another message
5. Agent responds to the new message (may or may not deliver)
6. User sees sporadic responses with missing context

Observed Behavior

From today's logs (21 messages received, only 13 dispatch completed, 10 send failures):

11:19:13 individual message send failed, continuing with remaining blocks
11:19:13 failed to deliver 1 of 1 message blocks
11:33:19 individual message send failed, continuing with remaining blocks
11:33:19 failed to deliver 1 of 1 message blocks
11:37:55 individual message send failed, continuing with remaining blocks
11:37:55 failed to deliver 1 of 1 message blocks

The agent continued operating normally after each failure, unaware that 7 of its responses never reached the user.

Expected Behavior

When delivery fails, the agent should be notified via a system event injected into its context:

{
  "type": "system",
  "text": "⚠️ Your last message to this conversation failed to deliver (error: Bot Framework 502 ConnectionError). The user did not receive your response. Consider retrying or acknowledging the gap."
}

This aligns with the approach proposed in #46830 (Message Delivery Failure Notification).

Current Code Path

In extensions/msteams/src/reply-dispatcher.ts, the flushPendingMessages function catches send errors and logs them at DEBUG level, but never feeds the failure back to the agent:

// Current: error is logged and forgotten
catch {
  failed += 1;
  params.log.debug?.("individual message send failed...");
}
if (failed > 0) params.log.warn?.(`failed to deliver ${failed} of ${total} message blocks`);
// ← No system event injection, no agent notification

Suggested Fix

After the flush loop, if failed > 0, inject a delivery failure event into the agent's session context. The existing onError callback in createReplyDispatcherWithTyping could be extended to support this, or a new onDeliveryFailure callback could be added.

Impact

• Users lose trust when responses disappear
• Agents cannot self-correct or retry
• Debugging requires log access (users don't have this)
• The delivery-recovery system helps for some cases, but only runs on gateway restart

Related

• [Feature]: Message Delivery Failure Notification #46830 (Feature: Message Delivery Failure Notification) — this is the same problem from the msteams perspective
• [Bug]: msteams typing/send errors logged as [object Object] — error not stringified #53910 (error stringification bug — makes debugging even harder)