A Teams channel thread should resolve to exactly one clean thread-qualified key, for example: ```text agent:main:msteams:channel:19:...@thread.tacv2:thread:1775973460425 ``` It should **not** produce a mixed or doubly-threaded key.

openclaw - ✅(Solved) Fix [Bug]: MSTeams malformed mixed thread session key from old-session reselection [1 pull requests, 1 comments, 1 participants]

hay7a4jhgqjw4 · 2026-04-14T20:01:34Z

[openclaw] In MSTeams channel-thread usage, I observed a malformed session key with two :thread: suffixes instead of a single clean thread-qualified key. Obser… In MSTeams channel-thread usage, I observed a **malformed session key with two `:thread:` suffixes** instead of a single clean thread-qualified key. Observed production example: ```text agent:main:msteams:channel:19:ca40d1f8e22a428db72a0dec922e0a1f@thread.tacv2:thread:1775961751186:thread:1775973460425 ``` The strongest current interpretation is that an **old thread session was selected first**, and then the **new thread id was appended afterward**, producing a mixed key of the form: ```text ...:thread:OLD_THREAD_ID:thread:NEW_THREAD_ID ``` This appears related to MSTeams thread/session isolation problems, but it is **not identical** to the already reported issue where different channel threads collapse to the same base session key. # PR #59294: fix(msteams): isolate thread sessions, outbound targeting, and attachment resolution - Repository: openclaw/openclaw - Author: atharva-getboon - State: open | merged: False - Link: https://github.com/openclaw/openclaw/pull/59294 ## Description (problem / solution / changelog) ## Summary Fixes #58615 — msteams channel threads share the same session key, causing cross-thread context bleed. - **Thread session isolation:** Each Teams channel thread gets its own session key via `resolveThreadSessionKeys()`, gated by `session.threadBindings.enabled` config - **Thread-scoped history:** `historyKey` is now thread-aware so `buildPendingHistoryContextFromMap` doesn't mix channel-level and thread-level history - **Outbound thread targeting:** `buildActivity()` sets `activity.replyToId` before any early returns so proactive sends (text + file attachments via SharePoint/OneDrive) land in the correct thread - **User mention preservation:** New `stripMSTeamsBotMentionTag()` strips only the bot's ` ` tag — other user mentions are preserved as `@Name` in agent context. A separate `commandText` (all mentions stripped) is used for slash command detection to avoid regressions. - **Key normalization:** Consistent `toLowerCase()` across session key, history key, and conversation store key derivations - **Thread file attachment fix:** Graph API fallback now triggers for mixed attachment types (text/html + file.download.info without downloadUrl), fixing file attachments not being visible in thread replies. Narrowed to only file-like content types to avoid unnecessary Graph calls for Adaptive Cards. - **Thread-aware debounce:** Debounce key includes `replyToId` when thread bindings enabled, preventing cross-thread message merging ## AI-Assisted PR 🤖 - [x] Marked as AI-assisted - [x] Fully tested (487 msteams tests pass, type-check clean, lint clean, build clean) - [x] Session logs available on request - [x] I understand what the code does - [x] Bot review conversations resolved with commit references ## Test plan - [x] 487/487 msteams extension tests pass (44 test files) - [x] Type-check (`pnpm tsgo`) clean - [x] Lint/format (`pnpm check`) clean - [x] Build (`pnpm build`) clean - [x] New unit tests for `stripMSTeamsBotMentionTag` (10 cases) - [x] New unit tests for `buildActivity` replyToId thread targeting (3 cases) - [x] New integration tests for thread isolation logic (12 cases) - [x] New unit tests for Graph API fallback on mixed attachment types (6 cases) - [ ] Manual verification: proactive sends with `activity.replyToId` land in correct Teams thread - [ ] Manual verification: file attachments in thread replies are visible to the bot 🤖 Generated with [Claude Code](https://claude.com/claude-code) ## Changed files - `extensions/bluebubbles/src/setup-core.ts` (modified, +2/-2) - `extensions/discord/src/channel-actions.test.ts` (modified, +1/-3) - `extensions/discord/src/group-policy.ts` (modified, +1/-4) - `extensions/feishu/src/channel.ts` (modified, +5/-3) - `extensions/googlechat/src/setup-surface.ts` (modified, +1/-3) - `extensions/googlechat/src/setup.test.ts` (modified, +1/-4) - `extensions/imessage/src/channel.ts` (modified, +3/-1) - `extensions/imessage/src/targets.test.ts` (modified, +2/-2) - `extensions/line/src/setup-surface.ts` (modified, +3/-1) - `extensions/matrix/src/matrix/client.test.ts` (modified, +1/-4) - `extensions/msteams/src/conversation-store.ts` (modified, +2/-0) - `extensions/msteams/src/inbound.test.ts` (modified, +56/-0) - `extensions/msteams/src/inbound.ts` (modified, +25/-0) - `extensions/msteams/src/messenger.test.ts` (modified, +25/-0) - `extensions/msteams/src/messenger.ts` (modified, +6/-0) - `extensions/msteams/src/monitor-handler.ts` (modified, +4/-0) - `extensions/msteams/src/monitor-handler/inbound-media.test.ts` (modified, +123/-42) - `extensions/msteams/src/monitor-handler/inbound-media.ts` (modified, +12/-3) - `extensions/msteams/src/monitor-handler/message-handler.test.ts` (added, +115/-0) - `extensions/msteams/src/monitor-handler/message-handler.ts` (modified, +74/-12) - `extensions

openclaw2026-04-14 20:01:34

ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

GitHub issue URL

Helpful · Quick feedback

GitHub stats

openclaw/openclaw#66771•Fetched 2026-04-15 06:24:26

View on GitHub

Comments

Participants

Timeline

Reactions

Author

hay7a4jhgqjw4

Participants

hay7a4jhgqjw4

Timeline (top)

commented ×1cross-referenced ×1renamed ×1subscribed ×1

In MSTeams channel-thread usage, I observed a malformed session key with two :thread: suffixes instead of a single clean thread-qualified key.

Observed production example:

agent:main:msteams:channel:19:[email protected]:thread:1775961751186:thread:1775973460425

The strongest current interpretation is that an old thread session was selected first, and then the new thread id was appended afterward, producing a mixed key of the form:

...:thread:OLD_THREAD_ID:thread:NEW_THREAD_ID

This appears related to MSTeams thread/session isolation problems, but it is not identical to the already reported issue where different channel threads collapse to the same base session key.

Root Cause

The malformed key is most naturally explained by old-session reselection before final new-thread attachment.
A strongest old-session candidate during local investigation was:
- fccdc361-9cc5-4138-84eb-51d23e12560a
A malformed-derived observed session entry was:
- 518b40fd-3292-43b0-92ff-3f000f3ffcca
Visible normal MSTeams message-flow code alone did not appear to be the strongest primary culprit.
Investigation also suggested that persisted conversation-binding / current-conversation selection could be relevant, but I do not want to overstate that as confirmed root cause yet.

Code Example

agent:main:msteams:channel:19:ca40d1f8e22a428db72a0dec922e0a1f@thread.tacv2:thread:1775961751186:thread:1775973460425

---

...:thread:OLD_THREAD_ID:thread:NEW_THREAD_ID

---

agent:main:msteams:channel:19:...@thread.tacv2:thread:1775973460425

RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Summary

In MSTeams channel-thread usage, I observed a malformed session key with two :thread: suffixes instead of a single clean thread-qualified key.

Observed production example:

agent:main:msteams:channel:19:[email protected]:thread:1775961751186:thread:1775973460425

The strongest current interpretation is that an old thread session was selected first, and then the new thread id was appended afterward, producing a mixed key of the form:

...:thread:OLD_THREAD_ID:thread:NEW_THREAD_ID

This appears related to MSTeams thread/session isolation problems, but it is not identical to the already reported issue where different channel threads collapse to the same base session key.

Version

OpenClaw: investigated on local environment updated to around 2026.4.12 / 2026.4.14
Channel: msteams

Expected behavior

A Teams channel thread should resolve to exactly one clean thread-qualified key, for example:

agent:main:msteams:channel:19:[email protected]:thread:1775973460425

It should not produce a mixed or doubly-threaded key.

Actual behavior

A malformed key was observed where:

an old thread id remained in the selected session path, and
the new thread id was appended afterward,
resulting in a double-thread key.

This can plausibly lead to wrong-thread routing, duplicate session entries, confusing UI/session state, and continued conversation on the wrong prior context.

Why this seems distinct from #58615

Issue #58615 describes a simpler failure mode:

different threads in the same Teams channel share the same base session key

The present symptom is different:

a session key already containing one thread id appears to be reused or reselected
then another thread id is attached
yielding ...:thread:old:thread:new

So even if #58615 explains one class of thread-isolation failure, it may not fully explain this mixed-key failure.

Current root-cause hypothesis

The current best explanation is:

old-session reselection happens first
then normal new-thread attachment happens afterward
the malformed mixed key is created as a result

At the moment, the most plausible fault-domain is not the visible normal thread-attach logic alone, but some session reselection path around:

conversation-binding resolution (resolveByConversation(...)-style path), and/or
native target-session / command-target injection

Additional observations

The malformed key is most naturally explained by old-session reselection before final new-thread attachment.
A strongest old-session candidate during local investigation was:
- fccdc361-9cc5-4138-84eb-51d23e12560a
A malformed-derived observed session entry was:
- 518b40fd-3292-43b0-92ff-3f000f3ffcca
Visible normal MSTeams message-flow code alone did not appear to be the strongest primary culprit.
Investigation also suggested that persisted conversation-binding / current-conversation selection could be relevant, but I do not want to overstate that as confirmed root cause yet.

Impact

This matters because a fix that only ensures "append the current thread id" may be insufficient if an incorrect prior session can still be reselected before that append step.

Reproduction status

I have confirmed this from production/local investigation and persisted session artifacts, but I do not yet have a minimal fresh-room reproduction recipe that isolates the exact responsible reselection path.

So this report is currently best treated as:

confirmed malformed-key symptom
plausible root-cause direction
further tracing still needed for precise reproducer

Related issue

#58615

extent analysis

TL;DR

The most likely fix involves modifying the session reselection logic to prevent old sessions from being reused before appending the new thread ID.

Guidance

Investigate the resolveByConversation method and conversation-binding resolution paths to identify where the old session is being reselected.
Verify that the normal thread-attach logic is working correctly and that the issue lies in the session reselection process.
Consider adding logging or debugging statements to track the session selection and thread attachment process to gain more insight into the issue.
Review the persisted conversation-binding and current-conversation selection logic to determine if it is contributing to the incorrect session reselection.

Example

No code snippet is provided as the issue does not contain sufficient information to create a specific example.

Notes

The root cause of the issue is still uncertain and requires further investigation to determine the exact responsible reselection path. The provided information suggests that the issue is related to the session reselection logic, but more tracing is needed to confirm this.

Recommendation

Apply a workaround to prevent old sessions from being reused before appending the new thread ID, such as clearing the session cache or implementing a check to ensure that the correct session is being used. This will help mitigate the issue until the root cause can be fully determined and a permanent fix can be implemented.

Vote matrix · Quick signals

Works

Did the solution work? Tap to confirm.

Easy Fix

Was it a quick fix?

Time Saver

Did it save you time?

Blocking

Was it severely blocking?

Common Issue

Are others likely hitting this too?

Flaky / Intermittent

Is it intermittent?

Verified / Reproducible

Can you reproduce it reliably?

FAQ

Expected behavior

A Teams channel thread should resolve to exactly one clean thread-qualified key, for example:

agent:main:msteams:channel:19:[email protected]:thread:1775973460425

It should not produce a mixed or doubly-threaded key.

#model compatibility #GPU setup #container setup #orchestration issue #cache issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

openclaw - ✅(Solved) Fix [Bug]: MSTeams malformed mixed thread session key from old-session reselection [1 pull requests, 1 comments, 1 participants]

Recommended Tools

GitHub issue graph ai analysis

Root Cause

Fix Action

Fixed

PR fix notes

PR #59294: fix(msteams): isolate thread sessions, outbound targeting, and attachment resolution

Description (problem / solution / changelog)

Summary

AI-Assisted PR 🤖

Test plan

Changed files

Code Example

Bug type

Summary

Version

Expected behavior

Actual behavior

Why this seems distinct from #58615

Current root-cause hypothesis

Additional observations

Impact

Reproduction status

Related issue

extent analysis

TL;DR

Guidance

Example

Notes

Recommendation

FAQ

Expected behavior

Still need to ship something?

RELATED_DISCOVERY

TRENDING