PR #63063: fix(msteams): resolve Graph chat ID for personal DM media downloads (#62219)

• Repository: openclaw/openclaw
• Author: feiskyer
• State: closed | merged: True
• Link: https://github.com/openclaw/openclaw/pull/63063

Description (problem / solution / changelog)

Summary

• Problem: Bot Framework personal DM conversation IDs (a:... format) are not valid Graph API chat IDs. When the direct Bot Framework attachment download fails and the code falls back to the Graph API path, buildMSTeamsGraphMessageUrls constructs URLs with the invalid a: ID, Graph returns 404 "Invalid ThreadId", and inbound media (images, documents) is silently dropped.
• Why it matters: Users sending files or images in Teams personal DMs see <media:document> / <media:image> placeholders but the agent receives no file content.
• What changed: Before calling resolveMSTeamsInboundMedia, resolve the real Graph chat ID via resolveGraphChatId() for personal DMs with a: conversation IDs. The resolved ID is cached in the conversation store so subsequent messages skip the API lookup.
• What did NOT change (scope boundary): The direct Bot Framework download path (smba.trafficmanager.net), the channel message path, and the buildMSTeamsGraphMessageUrls function itself are unchanged.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• 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

• Fixes #62219
• Related #41390 (same root cause for team/channel routing variant)
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: translateMSTeamsDmConversationIdForGraph synthesizes 19:{userId}_{appId}@unq.gbl.spaces which is not always accepted by the Graph /chats/{chatId}/messages endpoint. The resolveGraphChatId function (used in the send path for SharePoint uploads) was not used in the inbound media download path.
• Missing detection / guardrail: No validation that the conversation ID passed to buildMSTeamsGraphMessageUrls is a valid Graph chat ID for the /chats/ endpoint.
• Contributing context: The direct Bot Framework download (smba.trafficmanager.net) is the primary path and usually succeeds. The Graph fallback is reached when the direct download fails (e.g., auth issues, unsupported attachment types). The a: ID bug in the fallback path has been masked by the primary path working.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: extensions/msteams/src/attachments.helpers.test.ts
• Scenario the test should lock in: buildMSTeamsGraphMessageUrls correctly uses a resolved Graph chat ID (not the a: format) for personal DMs.
• Why this is the smallest reliable guardrail: The URL builder is a pure function — testing its output for different conversation ID formats directly validates the fix.
• Existing test that already covers this (if any): None — existing tests only covered channel and groupChat URLs.

User-visible / Behavior Changes

• Personal DM file/image attachments in Teams now reach the agent via the Graph API fallback path when the direct Bot Framework download fails.

Diagram (if applicable)

Before:
[Teams DM file] -> direct download (401) -> Graph fallback with a:xxx ID -> 404 Invalid ThreadId -> agent gets no file

After:
[Teams DM file] -> direct download (401) -> resolveGraphChatId(a:xxx) -> 19:real-id -> Graph fallback with real ID -> agent gets file

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No (reuses existing tokenProvider.getAccessToken and resolveGraphChatId)
• New/changed network calls? Yes — one additional Graph API call (/me/chats?$filter=...) per personal DM conversation, cached after first resolution
• Command/tool execution surface changed? No
• Data access scope changed? No
• The Graph /me/chats call uses the same token scope already used by the send path. The resolved chat ID is cached in the conversation store (same store used by send-context.ts).

Repro + Verification

Environment

• OS: Ubuntu 24.04 (Linux 6.17.0-1008-azure, x64) — AKS pod
• Runtime/container: OpenClaw 2026.3.13 (deployed), fix validated against upstream/main codebase
• Model/provider: N/A (attachment handling, not model inference)
• Integration/channel: MS Teams (Bot Framework), personal 1:1 DM
• Relevant config: dmPolicy: "open", groupPolicy: "open"

Steps

1. Configure MS Teams channel with bot registration
2. Send a file or image to the bot in a personal 1:1 DM
3. Observe: agent receives <media:image> or <media:document> placeholder but no file content

Expected

• Agent receives the file content via the Graph API fallback path

Actual

• Gateway log shows "graph media fetch empty" with hostedStatus: 403 / attachmentStatus: 404
• Agent dispatched without media

Evidence

• Failing test/log before + passing after
• Trace/log snippets

Before fix (live AKS pod):

08:28:07.327 received message
08:28:07.328 html attachment summary
08:28:08.100 graph media fetch empty
08:28:08.115 dispatching to agent      ← no media

After patching trafficmanager.net into auth allowlist (direct download fix, already on upstream/main):

Bot receives and processes image attachment successfully

Graph fallback path validated via instrumented logs:

convId=a:10OyQ1u7... type=personal isDM=true startsA=true

Confirmed the a: conversation ID reaches buildMSTeamsGraphMessageUrls unchanged when resolveGraphChatId is not called.

Human Verification (required)

• Verified scenarios: Personal DM image upload on live AKS pod (aksclaw-peni namespace), instrumented with debug logs to trace conversation ID flow through resolveMSTeamsInboundMedia and buildMSTeamsGraphMessageUrls
• Edge cases checked: Channel messages (verified 19: format passes through unchanged), a: prefix detection, conversation store caching path
• What you did not verify: Graph /me/chats resolution with delegated auth tokens (tested environment uses app-only tokens where /me returns 400; the resolveGraphChatId function is already used and tested in the send path)

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

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

Risks and Mitigations

• Risk: resolveGraphChatId calls Graph /me/chats which requires delegated auth — may return null with app-only tokens
  • Mitigation: Falls back to the synthetic translateMSTeamsDmConversationIdForGraph ID (same behavior as before this fix). The primary download path (smba.trafficmanager.net) handles most cases; this fix improves the Graph fallback path.
• Risk: Additional Graph API call per new DM conversation
  • Mitigation: Result is cached in the conversation store; subsequent messages use the cached value with zero API cost.

Changed files

• extensions/msteams/src/attachments.helpers.test.ts (modified, +22/-0)
• extensions/msteams/src/conversation-store-helpers.ts (modified, +5/-1)
• extensions/msteams/src/conversation-store.shared.test.ts (modified, +24/-0)
• extensions/msteams/src/monitor-handler/message-handler.ts (modified, +31/-1)

PR #63951: fix(msteams): fetch DM media via Bot Framework path for a: conversation IDs (#62219)

• Repository: openclaw/openclaw
• Author: sudie-codes
• State: closed | merged: True
• Link: https://github.com/openclaw/openclaw/pull/63951

Description (problem / solution / changelog)

Summary

Personal DM media fetches were failing because the plugin tried to use Graph /chats/{a:xxx}/messages/... which Graph rejects with "Invalid ThreadId" (only 19:xxx@thread.* / 19:[email protected] IDs are accepted on /chats). File attachments (PDFs, documents) sent in Teams personal DMs were silently dropped with only a <media:document> placeholder reaching the agent.

Fix

• Detect Bot Framework personal chat IDs (a: and 8:orgid: prefixes) via a new isBotFrameworkPersonalChatId helper.
• Route media fetches for those IDs through the Bot Framework v3 attachments endpoint (GET {serviceUrl}/v3/attachments/{attachmentId} + .../views/{viewId}) using the bot's Bot Framework token scope.
• Attachment IDs are extracted from the HTML attachments in the activity via the new extractMSTeamsHtmlAttachmentIds helper (un-sliced counterpart to the existing diagnostic summary).
• When the conversation is a BF personal chat, skip the Graph fallback entirely so we do not waste a call that is guaranteed to fail with "Invalid ThreadId".
• Keep the existing Graph routing intact for thread-format conversation IDs (19:xxx@thread.*) and group chats.
• Wire activity.serviceUrl through resolveMSTeamsInboundMedia so the new code path has the Bot Framework service URL it needs.

Fixes #62219

Test plan

• Unit test: a: and 8:orgid: IDs route to Bot Framework, Graph URLs never built
• Unit test: 19: IDs continue to route to Graph (regression)
• Unit test: missing serviceUrl leaves both paths inert (safe degradation)
• Unit test: missing attachment IDs on BF DM logs a diagnostic
• Unit test: bot-framework helper fetches attachment info then view and saves media
• Unit test: bot-framework helper handles 401, missing views, oversized views, token failure
• Full extensions/msteams suite passes (595 tests)
• Manual: send a PDF in a personal DM with the bot

Changed files

• extensions/msteams/src/attachments.ts (modified, +6/-0)
• extensions/msteams/src/attachments/bot-framework.test.ts (added, +317/-0)
• extensions/msteams/src/attachments/bot-framework.ts (added, +306/-0)
• extensions/msteams/src/attachments/html.ts (modified, +31/-0)
• extensions/msteams/src/monitor-handler/inbound-media.test.ts (modified, +151/-1)
• extensions/msteams/src/monitor-handler/inbound-media.ts (modified, +49/-1)
• extensions/msteams/src/monitor-handler/message-handler.ts (modified, +1/-0)

PR #49126: WORKING: All Microsoft Issues and PRs

• Repository: openclaw/openclaw
• Author: BradGroux
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/49126

Description (problem / solution / changelog)

Microsoft Ecosystem Issues & PRs Tracker

Purpose: Living checklist for maintainers to track all open Microsoft-related issues and PRs (Teams, Windows, WSL, Azure, M365/SharePoint).

How to use:

• Mark items resolved by editing this PR body and changing [ ] to [x]
• Claim items by adding your GitHub handle to the Assignee column
• Priority guide: P0 = crash/blocker, P1 = significant bug/regression, P2 = minor bug/enhancement, P3 = nice-to-have/stale
• Items marked (stale) have been flagged by the stale bot due to inactivity

Last updated: 2026-04-11 (full audit: refreshed Microsoft metrics, reconciled closed sudie-codes PRs and linked issues, and updated open PR backlog)

Summary

1. MS Teams Channel Plugin — Issues

Bugs / Crashes

Feature Requests

2. MS Teams Channel Plugin — PRs

Audit Notes — 2026-04-10

• Closed issues marked resolved today: #58001, #58249, #55383.
• Closed/merged Microsoft PRs added today: #62674, #63942, #63951, #63953, #64089.

Audit Notes — 2026-04-11

• Recomputed summary metrics directly from the tracker body sections instead of GitHub label counts.
• MS Teams tracker section currently contains 68 issues and 84 PRs (115 resolved, 37 remaining).
• Windows tracker section currently contains 197 issues and 52 PRs (101 resolved, 148 remaining).
• WSL tracker section currently contains 0 issues and 0 PRs (0 resolved, 0 remaining).
• Azure tracker section currently contains 0 issues and 0 PRs (0 resolved, 0 remaining).
• SharePoint / M365 tracker section currently contains 0 issues and 0 PRs (0 resolved, 0 remaining).
• Confirmed merged sudie-codes Microsoft PRs reflected in the tracker include: #49582, #49583, #49585, #49587, #49925, #49929, #51643, #51646, #51647, #53432, #54832, #57528, #57529, #57530, #62674, #62713, #62715, #62716, #63942, #63945, #63949, #63951, #63953, #64087, #64088, #64089, #64641, #64645, #64646, #64652.
• Closed without merge in that queue: #49580, #63954, #63963, #63964.

3. Windows Platform — Issues

Installation / Setup / Gateway

Feature Requests

4. Windows Platform — PRs

5. WSL (Windows Subsystem for Linux) — Issues

WSL — PRs

6. Azure (Provider / Infrastructure) — Issues

Azure — PRs

7. Microsoft 365 / SharePoint — Issues

Appendix: P0 Blockers (Start Here)

Appendix: Stale Items (Consider Closing)

Audit Notes

• Refreshed MS Teams tracker entries for merged fixes #62713, #62715, and #62716.
• Backfilled missed Windows tracker entries from recent merged PRs/issues during audit.
• Corrected summary counts after resolving stale/missed tracker rows.

Changed files

• MICROSOFT_TRACKER.md (added, +546/-0)