null value passes through as the string "null"

null is not undefined, so the null guard does not fire — typeof null === "object", which falls through to JSON.stringify(null) and returns the truthy string "null". That string is then forwarded to the agent as the message body, which is almost certainly not intended.

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

Comment:
**`null` value passes through as the string `"null"`**

`null` is not `undefined`, so the `null` guard does not fire — `typeof null === "object"`, which falls through to `JSON.stringify(null)` and returns the truthy string `"null"`. That string is then forwarded to the agent as the message body, which is almost certainly not intended.

```suggestion
  if (value == null) {
    return null;
  }
```

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

No-value path falls through to originalRun

When text is falsy the code logs "skipping" but then falls through to return originalRun.call(handler, context), passing the adaptiveCard/action invoke to the normal handler chain. That chain dispatches the activity as a message, which contradicts the intent of "skipping". A missing return here means the invoke is still processed.

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

Comment:
**No-value path falls through to `originalRun`**

When `text` is falsy the code logs "skipping" but then falls through to `return originalRun.call(handler, context)`, passing the `adaptiveCard/action` invoke to the normal handler chain. That chain dispatches the activity as a message, which contradicts the intent of "skipping". A missing `return` here means the invoke is still processed.

```suggestion
        deps.log.debug?.("skipping adaptive card action invoke without value payload");
        return;
```

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

serializeAdaptiveCardActionValue() will forward null payloads as the literal string "null" (since JSON.stringify(null) returns "null"), which can result in a synthetic message being dispatched for Action.Submit clicks that carry no usable data. Consider treating null the same as undefined, and also guard against JSON.stringify(...) returning undefined (e.g., for values like functions/symbols) by normalizing that to null as well.

Wrap adaptive invoke forwarding in existing error guard

The new adaptiveCard/action branch calls handleTeamsMessage(...) directly, but unlike the normal onMessage path it is not inside the try/catch that reports failures via runtime.error. If this call throws (for example from debounce/runtime wiring failures), the exception bubbles out of registerMSTeamsHandlers, and createMSTeamsAdapter.process suppresses invoke errors for type === "invoke", so the action is silently dropped with no diagnostic. Reusing the same guarded wrapper as onMessage avoids losing observability for this new path.

Useful? React with 👍 / 👎.

Mark adaptive invokes as mentioned before message forwarding

Forwarding adaptiveCard/action invokes through handleTeamsMessage without any mention override means channel submissions still fail under default policy: resolveMSTeamsReplyPolicy defaults requireMention to true, and wasMSTeamsBotMentioned only checks mention entities. Adaptive invoke payloads typically lack mention entities, so the message handler’s mention gate drops these synthetic messages and the button click is ignored in channels. Please set a mention/bypass signal for this converted activity path (or skip mention gating for this invoke type).

Useful? React with 👍 / 👎.

Preserve thread anchor when converting adaptive invokes

This conversion only changes type/text, so the synthetic message keeps the invoke activity ID. Downstream Teams reply threading uses activity.id as the anchor (for example via conversation references and default reply target logic), but adaptive-card clicks in channel threads typically identify the clicked card message via replyToId, not the invoke ID itself. In that case replies can be posted out-of-thread or fail to thread correctly. When constructing this message-shaped activity, carry the thread anchor from replyToId (or explicitly set the reply target) instead of leaving the invoke ID as the message ID.

Useful? React with 👍 / 👎.

Preserve adaptive action thread target in converted message

This invoke-to-message conversion reuses ctx.sendActivity, but that sender was created from the original invoke context where replyToActivityId is bound to the invoke activity.id; as a result, replies from this path can target the invoke ID instead of the clicked card message (replyToId) in channel threads. In practice this can post out-of-thread (or fail to thread) for adaptive card submits. Ensure this path explicitly preserves the thread anchor (for example by routing with a context/proactive reference keyed to replyToId, or by setting outbound replyToId explicitly).

Useful? React with 👍 / 👎.

Bypass debounce for adaptive card submit events

Forwarding adaptiveCard/action through handleTeamsMessage(...) routes these synthetic submits into the normal inbound debouncer, and when messages.inbound.debounceMs is non-zero the handler can merge multiple rapid button clicks from the same sender/conversation into one combined payload (the flush path concatenates texts and keeps only the last context in extensions/msteams/src/monitor-handler/message-handler.ts). For adaptive actions this changes semantics (distinct submits become one turn), so quick multi-click workflows can execute the wrong action or lose submissions.

Useful? React with 👍 / 👎.