fix(msteams): pass teamId and teamName to resolveAgentRoute() [AI-assisted] by slbteam08 · Pull Request #50214 · openclaw/openclaw

slbteam08 · 2026-03-19T04:48:41Z

The upstream 2026.3.13 package correctly extracts teamId and teamName from activity.channelData but was not forwarding them into the resolveAgentRoute() call. This caused team-scoped agent routing to fail in group/channel conversations where team context is required.

Fixes: resolveAgentRoute missing teamId + peer.teamName fields

Summary

resolveAgentRoute() in the MSTeams message handler was not receiving
teamId or peer.teamName, even though both values were correctly
extracted from activity.channelData earlier in the same function.

This caused team-scoped agent routing to silently fail in group and
channel conversations where team context is needed to resolve the
correct agent.

Root Cause

In extensions/msteams/src/monitor-handler/message-handler.ts, the
call to resolveAgentRoute() was missing two fields:

 const route = core.channel.routing.resolveAgentRoute({
   cfg,
   channel: "msteams",
+  teamId,
   peer: {
     kind: isDirectMessage ? "direct" : isChannel ? "channel" : "group",
     id: isDirectMessage ? senderId : conversationId,
+    teamName,
   },
 });

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Closes #
Related #

User-visible / Behavior Changes

List user-visible changes (including defaults/config).
If none, write None.

Agent routing in MSTeams group/channel conversations now correctly resolves when team context is present. No change for DMs.

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)
If any Yes, explain risk + mitigation:

Repro + Verification

Environment

OS: Linux / Azure
Runtime/container:
Model/provider:
Integration/channel (if any): MSTeams
Relevant config (redacted):

Steps

Add binding objects in openclaw.json with match.teamId attribute set

Expected

Conversations in the team bound to specific agent

Actual

Binding rules not hit and message routed to the default agent

Evidence

Attach at least one:

Failing test/log before + passing after
Trace/log snippets
Screenshot/recording
Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

Verified scenarios: Team binding in MS Teams
Edge cases checked:
What you did not verify:

Verified against the published openclaw@2026.3.13 package, which contains the correct implementation. This PR aligns the source with what is already shipped. Lightly tested — the fix matches the published package exactly.

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.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

Backward compatible? Yes
Config/env changes? No
Migration needed? No
If yes, exact upgrade steps:

Failure Recovery (if this breaks)

How to disable/revert this change quickly: Revert this commit. No config changes required.
Files/config to restore:
Known bad symptoms reviewers should watch for:

Risks and Mitigations

List only real risks for this PR. Add/remove entries as needed. If none, write None.

Risk: None
- Mitigation: None

AI Disclosure

AI-assisted (identified and implemented with OpenClaw / Claude Sonnet)
Lightly tested — verified by diffing against the published package
Author understands what the code does
Prompts/session: fix was identified by diffing extensions/msteams/src/monitor-handler/message-handler.ts between the installed openclaw@2026.3.13 npm package and the fork source

greptile-apps · 2026-03-19T04:51:44Z

Greptile Summary

This PR adds teamId and teamName to the resolveAgentRoute() call in the MSTeams message handler, aiming to fix team-scoped agent routing in group/channel conversations. The teamId addition is the correct and functional fix — it maps to ResolveAgentRouteInput.teamId and is actively used by the routing engine for team-scoped binding resolution. However, teamName is placed inside the peer object, which is typed as RoutePeer = { kind: ChatType; id: string } in src/routing/resolve-route.ts — a type that has no teamName field. This causes a TypeScript excess property error on the object literal, and even if it were to compile, resolveAgentRoute immediately strips peer to only kind and id, so teamName is silently discarded and has no effect on routing.

Key findings:

teamId addition (line 384): correct fix, functional, aligns with how the routing engine resolves team-scoped bindings
teamName inside peer (line 388): excess property not present in RoutePeer, TypeScript will reject this as a type error on the object literal; additionally the routing function never reads it from peer
The PR description claims this aligns with openclaw@2026.3.13 — if that package updated RoutePeer to include teamName, the type definition in this source repo needs to be updated accordingly; if not, teamName should be removed from the peer object

Confidence Score: 2/5

The core fix (teamId) is correct, but teamName inside peer is a TypeScript type error that will break compilation and serves no routing purpose even if it compiled.
The teamId addition is functionally correct and aligned with the existing type definitions. However, teamName inside peer is an excess property not present in RoutePeer, which will cause a TypeScript compile error. Since teamName is also stripped and never used by resolveAgentRoute, it has no effect on routing even if it were to compile successfully. The PR needs to either remove teamName from peer or update the RoutePeer type to include it before this can merge cleanly.
extensions/msteams/src/monitor-handler/message-handler.ts lines 385-389 — the teamName field in peer needs to be resolved; src/routing/resolve-route.ts may also need the RoutePeer type updated if teamName is intentional.

Prompt To Fix All With AI

This is a comment left during a code review.
Path: extensions/msteams/src/monitor-handler/message-handler.ts
Line: 385-389

Comment:
**`teamName` in `peer` is a type error and is silently ignored by routing**

`RoutePeer` is typed as `{ kind: ChatType; id: string }` with no `teamName` field (`src/routing/resolve-route.ts:21-24`). Passing `teamName` here is an excess property that TypeScript should reject on the object literal.

More importantly, even if TypeScript accepted it, the routing function immediately strips `peer` down to only `kind` and `id`:

```typescript
// src/routing/resolve-route.ts:617-622
const peer = input.peer
  ? {
      kind: normalizeChatType(input.peer.kind) ?? input.peer.kind,
      id: normalizeId(input.peer.id),
    }
  : null;
```

`teamName` is never read from `peer` anywhere in `resolveAgentRoute`. There is no `teamName` field in `ResolveAgentRouteInput` either.

The `teamId` addition at line 384 is the correct and functional fix — it maps to `ResolveAgentRouteInput.teamId` (line 34) and is actively used for team-scoped binding resolution. The `teamName` in `peer` should either be removed (if not needed by the published package's routing logic), or `RoutePeer` needs to be extended to include `teamName?: string` if the `2026.3.13` package updated the type.

```suggestion
      peer: {
        kind: isDirectMessage ? "direct" : isChannel ? "channel" : "group",
        id: isDirectMessage ? senderId : conversationId,
      },
```

How can I resolve this? If you propose a fix, please make it concise.

_{Last reviewed commit: "fix(msteams): pass t..."}

The upstream 2026.3.13 package correctly extracts teamId and teamName from activity.channelData but was not forwarding them into the resolveAgentRoute() call. This caused team-scoped agent routing to fail in group/channel conversations where team context is required. Fixes: resolveAgentRoute missing teamId + peer.teamName fields

RoutePeer is typed as { kind: ChatType; id: string } with no teamName field. Passing teamName was an excess property that TypeScript rejects, and it was stripped by routing anyway. The teamId addition is the sole functional fix — it maps to ResolveAgentRouteInput.teamId and is used for team-scoped binding resolution. Addresses Greptile review comment.

slbteam08

Accepted — removed teamName from peer. RoutePeer has no teamName field per the published type definitions; teamId at the top level is the correct and only functional change needed.

@slbteam08

…aw#50214) thanks @slbteam08

@slbteam08

…aw#50214) thanks @slbteam08

@slbteam08

…aw#50214) thanks @slbteam08

@slbteam08

…aw#50214) thanks @slbteam08

openclaw-barnacle Bot added channel: msteams Channel integration: msteams size: XS labels Mar 19, 2026

greptile-apps Bot reviewed Mar 19, 2026

View reviewed changes

Comment thread extensions/msteams/src/monitor-handler/message-handler.ts

Claw added 2 commits March 19, 2026 13:22

slbteam08 force-pushed the fix/msteams-resolve-agent-route-team-context branch from 7660c62 to b3c3bcd Compare March 19, 2026 05:22

slbteam08 added 2 commits March 22, 2026 22:19

Merge branch 'main' into fix/msteams-resolve-agent-route-team-context

d47e3d3

Merge branch 'main' into fix/msteams-resolve-agent-route-team-context

7784beb

slbteam08 commented Mar 23, 2026

View reviewed changes

Merge branch 'main' into fix/msteams-resolve-agent-route-team-context

db82319

BradGroux mentioned this pull request Mar 26, 2026

WORKING: All Microsoft Issues and PRs #49126

Closed

BradGroux merged commit 2427304 into openclaw:main Apr 1, 2026
49 of 59 checks passed

BradGroux mentioned this pull request Apr 1, 2026

fix(msteams): pass teamId into inbound route resolution #39352

Closed

github-actions Bot mentioned this pull request Apr 1, 2026

📡 Upstream Digest — 2026-04-01 16:45 UTC curtismercier/openclaw-mods#434

Open

steipete pushed a commit to duncanita/openclaw that referenced this pull request Apr 4, 2026

fix(msteams): pass teamId and teamName to resolveAgentRoute() (opencl…

a42184f

…aw#50214) thanks @slbteam08

lovewanwan pushed a commit to lovewanwan/openclaw that referenced this pull request Apr 28, 2026

fix(msteams): pass teamId and teamName to resolveAgentRoute() (opencl…

efe3386

…aw#50214) thanks @slbteam08

ogt-redknie pushed a commit to ogt-redknie/OPENX that referenced this pull request May 2, 2026

fix(msteams): pass teamId and teamName to resolveAgentRoute() (opencl…

ecfa757

…aw#50214) thanks @slbteam08

github-actions Bot pushed a commit to Desicool/openclaw that referenced this pull request May 9, 2026

fix(msteams): pass teamId and teamName to resolveAgentRoute() (opencl…

ac30111

…aw#50214) thanks @slbteam08

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix(msteams): pass teamId and teamName to resolveAgentRoute() [AI-assisted]#50214

fix(msteams): pass teamId and teamName to resolveAgentRoute() [AI-assisted]#50214
BradGroux merged 5 commits intoopenclaw:mainfrom
slbteam08:fix/msteams-resolve-agent-route-team-context

slbteam08 commented Mar 19, 2026 •

edited

Loading

Uh oh!

greptile-apps Bot commented Mar 19, 2026

Uh oh!

Uh oh!

slbteam08 left a comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

slbteam08 commented Mar 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Root Cause

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

User-visible / Behavior Changes

Security Impact (required)

Repro + Verification

Environment

Steps

Expected

Actual

Evidence

Human Verification (required)

Review Conversations

Compatibility / Migration

Failure Recovery (if this breaks)

Risks and Mitigations

AI Disclosure

Uh oh!

greptile-apps Bot commented Mar 19, 2026

Greptile Summary

Confidence Score: 2/5

Uh oh!

Uh oh!

slbteam08 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

slbteam08 commented Mar 19, 2026 •

edited

Loading