Bug Report
Version: 2026.3.23 (ccfeecb)
OS: Linux 6.8.12-15-pve (x64)
Channel: msteams (bundled plugin)
Problem
When the msteams typing indicator or message send fails, the error is logged as [object Object] instead of a useful error message:
msteams typing action=start failed: [object Object]
This makes debugging delivery failures extremely difficult since the actual error (e.g., ECONNREFUSED, 502 ConnectionError, auth failure) is hidden.
Root Cause
Two locations:
1. logTypingFailure in src/channels/logging.ts
params.log(`${params.channel} typing${action} failed${target}: ${String(params.error)}`);
String(err) on a non-Error object (e.g., an Axios error or Bot Framework SDK error object) produces [object Object].
Fix:
const errMsg = params.error instanceof Error
? params.error.message
: (typeof params.error === "string" ? params.error : JSON.stringify(params.error));
params.log(`${params.channel} typing${action} failed${target}: ${errMsg}`);
Or reuse the existing formatUnknownError() utility that already exists in the msteams extension code.
2. Send failure catch block in extensions/msteams/src/reply-dispatcher.ts
catch {
failed += 1;
params.log.debug?.("individual message send failed, continuing with remaining blocks");
}
The catch block has no error variable — the error is completely discarded. This means when message delivery fails, there is zero information about why.
Fix:
catch (err) {
failed += 1;
params.log.debug?.("individual message send failed, continuing with remaining blocks", {
error: formatUnknownError(err)
});
}
Impact
- Users see intermittent message delivery failures with no way to diagnose the cause
- The actual errors (Bot Framework 502, ECONNREFUSED, auth errors) are hidden
formatUnknownError() already exists in the codebase and handles all error types — it just needs to be used in these two locations
Reproduction
- Configure msteams channel
- Send a message when Bot Framework has intermittent connectivity issues
- Check gateway logs — typing and send failures show
[object Object] with no detail
Related
Bug Report
Version: 2026.3.23 (ccfeecb)
OS: Linux 6.8.12-15-pve (x64)
Channel: msteams (bundled plugin)
Problem
When the msteams typing indicator or message send fails, the error is logged as
[object Object]instead of a useful error message:This makes debugging delivery failures extremely difficult since the actual error (e.g.,
ECONNREFUSED,502 ConnectionError, auth failure) is hidden.Root Cause
Two locations:
1.
logTypingFailureinsrc/channels/logging.tsString(err)on a non-Error object (e.g., an Axios error or Bot Framework SDK error object) produces[object Object].Fix:
Or reuse the existing
formatUnknownError()utility that already exists in the msteams extension code.2. Send failure catch block in
extensions/msteams/src/reply-dispatcher.tsThe catch block has no error variable — the error is completely discarded. This means when message delivery fails, there is zero information about why.
Fix:
Impact
formatUnknownError()already exists in the codebase and handles all error types — it just needs to be used in these two locationsReproduction
[object Object]with no detailRelated