groupPolicy: "disabled" is not respected for group chats

senderGroupPolicy is always computed as "allowlist" or "open" — it never becomes "disabled". This means reactions from group chats will still be processed and fire system events even when the user has configured msteamsCfg.groupPolicy === "disabled".

In message-handler.ts, the equivalent computation correctly derives "disabled" by first evaluating the configured groupPolicy:

// message-handler.ts (correct approach)
const groupPolicy = !isDirectMessage && msteamsCfg
  ? (msteamsCfg.groupPolicy ?? defaultGroupPolicy ?? "allowlist")
  : "disabled";

const senderGroupPolicy =
  groupPolicy === "disabled" ? "disabled"
  : effectiveGroupAllowFrom.length > 0 ? "allowlist"
  : "open";

The reaction handler needs the same gate. Without it a groupPolicy: "disabled" config silences regular messages but still leaks reaction events to the agent.

This is a comment left during a code review.
Path: extensions/msteams/src/monitor-handler/reaction-handler.ts
Line: 93-94

Comment:
**`groupPolicy: "disabled"` is not respected for group chats**

`senderGroupPolicy` is always computed as `"allowlist"` or `"open"` — it never becomes `"disabled"`. This means reactions from group chats will still be processed and fire system events even when the user has configured `msteamsCfg.groupPolicy === "disabled"`.

In `message-handler.ts`, the equivalent computation correctly derives `"disabled"` by first evaluating the configured `groupPolicy`:

```ts
// message-handler.ts (correct approach)
const groupPolicy = !isDirectMessage && msteamsCfg
  ? (msteamsCfg.groupPolicy ?? defaultGroupPolicy ?? "allowlist")
  : "disabled";

const senderGroupPolicy =
  groupPolicy === "disabled" ? "disabled"
  : effectiveGroupAllowFrom.length > 0 ? "allowlist"
  : "open";
```

The reaction handler needs the same gate. Without it a `groupPolicy: "disabled"` config silences regular messages but still leaks reaction events to the agent.

```suggestion
    const configuredGroupPolicy =
      !isDirectMessage && msteamsCfg
        ? (msteamsCfg.groupPolicy ?? "allowlist")
        : "disabled";
    const senderGroupPolicy =
      configuredGroupPolicy === "disabled" ? "disabled" : effectiveGroupAllowFrom.length > 0 ? "allowlist" : ("open" as const);
```

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

Channel/team-level allowlist is not enforced for reactions

message-handler.ts calls resolveMSTeamsRouteConfig and then explicitly drops events when a team or channel is not on the configured allowlist:

// message-handler.ts
const channelGate = resolveMSTeamsRouteConfig({ cfg: msteamsCfg, teamId, teamName, conversationId, channelName });
// ...
if (groupPolicy === "allowlist") {
  if (channelGate.allowlistConfigured && !channelGate.allowed) {
    // drop: not in team/channel allowlist
    return;
  }
  if (effectiveGroupAllowFrom.length === 0 && !channelGate.allowlistConfigured) {
    // drop: allowlist policy but nothing configured
    return;
  }
}

The reaction handler skips resolveMSTeamsRouteConfig entirely. As a result, reactions arriving from a channel/team that is explicitly blocked in config will still reach the agent via enqueueSystemEvent. This is inconsistent with message handling and can surface information from channels the operator intended to block.

This is a comment left during a code review.
Path: extensions/msteams/src/monitor-handler/reaction-handler.ts
Line: 122-130

Comment:
**Channel/team-level allowlist is not enforced for reactions**

`message-handler.ts` calls `resolveMSTeamsRouteConfig` and then explicitly drops events when a team or channel is not on the configured allowlist:

```ts
// message-handler.ts
const channelGate = resolveMSTeamsRouteConfig({ cfg: msteamsCfg, teamId, teamName, conversationId, channelName });
// ...
if (groupPolicy === "allowlist") {
  if (channelGate.allowlistConfigured && !channelGate.allowed) {
    // drop: not in team/channel allowlist
    return;
  }
  if (effectiveGroupAllowFrom.length === 0 && !channelGate.allowlistConfigured) {
    // drop: allowlist policy but nothing configured
    return;
  }
}
```

The reaction handler skips `resolveMSTeamsRouteConfig` entirely. As a result, reactions arriving from a channel/team that is explicitly blocked in config will still reach the agent via `enqueueSystemEvent`. This is inconsistent with message handling and can surface information from channels the operator intended to block.

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

Reaction authorization is not aligned with the message handler: this logic ignores msteamsCfg.groupPolicy (including disabled) and the team/channel allowlist gate (resolveMSTeamsRouteConfig). As written, reactions in group/channel conversations can be enqueued even when group messaging is disabled or restricted by team/channel allowlist. Please reuse the same groupPolicy + channelGate checks as message-handler.ts before allowing reactions in non-DM conversations.

contextKey falls back to Date.now() when activity.id is missing. This makes reaction events non-deterministic across retries/replays and can create duplicate system events. Consider using a stable fallback (e.g. "unknown") and/or incorporating stable fields like replyToId, senderId, direction, and reaction types, similar to how the message handler uses activity.id ?? "unknown".

This handler is newly introduced but there are currently no MSTeams tests exercising reaction events (added/removed), authorization decisions (dmPolicy/groupPolicy/allowlists), and the resulting enqueueSystemEvent payload. Adding a small Vitest suite for createMSTeamsReactionHandler (similar to existing message-handler.*.test.ts) would help prevent regressions.

PR description says reaction summaries are emoji-mapped using colon codes like :thumbsup:, but the implementation emits raw Unicode emoji (e.g. 👍). Please either update the PR description/docs to match the actual output or change the mapping/formatter to emit the documented :name: form for consistency with the documented behavior.

MSTeamsActivityHandler now requires onReactionsAdded/onReactionsRemoved. This breaks existing MSTeams tests that construct minimal handler stubs (e.g. monitor-handler.file-consent.test.ts's createActivityHandler()), and will also throw at runtime if a stub/older SDK handler lacks these hooks. Either update the stubs/tests to implement these methods, or make the new hooks optional and guard the registrations in registerMSTeamsHandlers.

Honor configured groupPolicy in reaction access checks

senderGroupPolicy is computed solely from whether effectiveGroupAllowFrom is empty, which forces group reactions into open when no list exists and never honors channels.msteams.groupPolicy (including disabled). Message intake explicitly resolves and enforces group policy in extensions/msteams/src/monitor-handler/message-handler.ts:159-236, so this regression allows group/channel reactions to be enqueued even when group traffic is configured to be blocked.

Useful? React with 👍 / 👎.

Enforce team/channel allowlist gate for reactions

This authorization path checks sender allowlists but never applies the team/channel route allowlist (teams/channels) that message handling enforces via resolveMSTeamsRouteConfig in extensions/msteams/src/monitor-handler/message-handler.ts:168-247. In deployments that scope MSTeams ingestion to specific teams/channels, reactions from excluded conversations will still pass here and be delivered to enqueueSystemEvent.

Useful? React with 👍 / 👎.

Guard reaction hook registration against missing SDK methods

registerMSTeamsHandlers now calls handler.onReactionsAdded(...) and handler.onReactionsRemoved(...) unconditionally, but the previous handler contract only required onMessage/onMembersAdded, and existing in-repo stubs (for example in extensions/msteams/src/monitor-handler.file-consent.test.ts) still omit reaction hooks. In any environment where the provided handler object lacks these methods (custom wrappers, older SDK surfaces, or test doubles), initialization throws a TypeError and the Teams monitor cannot start.

Useful? React with 👍 / 👎.

Respect open groupPolicy in reaction authorization

createMSTeamsReactionHandler unconditionally returns when access.decision !== "allow", but access is computed with senderGroupPolicy that becomes "allowlist" whenever effectiveGroupAllowFrom is non-empty. In a configuration with channels.msteams.groupPolicy: "open" plus a populated groupAllowFrom, group reactions from users outside that list are incorrectly dropped, even though open policy should allow them; createMSTeamsMessageHandler only applies this pre-check to DMs (message-handler.ts), so this is a reaction-only regression.

Useful? React with 👍 / 👎.