Greptile Summary

This PR fixes a real production bug where proactive fallback messages in Teams channel threads were landing as new top-level channel posts instead of staying in the original thread. The root cause was sendProactively unconditionally clearing activityId (the thread-root message ID for channels), and the fix correctly preserves it only when conversationType === "channel".

The logic change and the two new test cases are sound. One thing worth confirming: sendProactively is shared between the revoked-proxy fallback path and the replyStyle: "top-level" direct path (line 543). With this fix, a top-level send for a channel conversation would also preserve activityId, routing the message into the thread rather than creating a new top-level post. There is no test covering replyStyle: "top-level" + conversationType: "channel", so the intended behavior in that combination is not verified. If top-level sends are never used for channel conversations in practice this is a non-issue, but an explicit test would confirm the contract either way.

Confidence Score: 5/5

Safe to merge; the fix is correct for the stated use case and all existing tests pass.

The core change is minimal, well-targeted, and accompanied by two new test cases. The only remaining concern is a test gap for the top-level + channel combination, which is a P2 suggestion that does not block merge.

No files require special attention; the P2 note on messenger.ts is a suggestion to add one more test case.

This is a comment left during a code review.
Path: extensions/msteams/src/messenger.ts
Line: 502-506

Comment:
**`sendProactively` used by both fallback AND `top-level` path**

`sendProactively` is called in two places: once as the revoked-proxy fallback (the case this PR targets), and once unconditionally at line 543 for the `top-level` replyStyle.

With this change, a call to `sendMSTeamsMessages` with `replyStyle: "top-level"` and `conversationType: "channel"` will now *preserve* `activityId` — routing the message into the thread rather than creating a new top-level post. This contradicts the intent of the `top-level` replyStyle.

The existing test for top-level sends (`"sends top-level messages via continueConversation and strips activityId"`) uses `baseRef` with no `conversationType`, so `conversationType` resolves to `undefined` and `activityId` is still cleared — the test doesn't catch this case.

If `replyStyle: "top-level"` is never paired with channel conversations in practice this has no impact, but it would be worth adding an explicit test case to lock in the expected behavior, e.g.:

```ts
it("clears activityId in top-level send for channel conversations", async () => {
  const seen: { reference?: unknown; texts: string[] } = { texts: [] };
  const adapter: MSTeamsAdapter = {
    continueConversation: async (_appId, reference, logic) => {
      seen.reference = reference;
      await logic({ sendActivity: createRecordedSendActivity(seen.texts), ... });
    },
    ...
  };

  await sendMSTeamsMessages({
    replyStyle: "top-level",
    adapter,
    appId: "app123",
    conversationRef: { ...baseRef, conversation: { ...baseRef.conversation, conversationType: "channel" } },
    messages: [{ text: "hello" }],
  });

  const ref = seen.reference as { activityId?: string };
  expect(ref.activityId).toBeUndefined(); // or .toBe("activity123") — confirm intent
});
```

Alternatively, if top-level sends for channels *should* preserve the thread `activityId`, document that explicitly.

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

_{Reviews (1): Last reviewed commit: "fix(msteams): preserve thread context in..." | Re-trigger Greptile}

Good catch on the top-level + channel path — updated the fix to use a preserveThread parameter on sendProactively() so the thread context is only preserved when called from the revoked-proxy fallback (where the original intent was thread), not from the explicit top-level path.

Changes in the force-push:

• sendProactively() now accepts { preserveThread?: boolean } (defaults to false)
• Only the onRevoked fallback passes preserveThread: true
• Added the suggested test: clears activityId in top-level send for channel conversations
• 415 tests passing (37 files)

— Fitzy 🐾

Hey @onutc — would appreciate your eyes on this when you get a chance. This fixes a production issue where channel thread replies fall back to top-level channel posts when the Bot Framework turn context proxy is revoked (long-running agent responses).

The fix is minimal (preserves activityId in sendProactively only when called from the revoked-proxy fallback for channel conversations), and we added 3 test cases covering the thread, personal, and top-level+channel paths.

The failing CI check (checks-windows-node-test-6) is a pre-existing Windows flake in test/test-env.test.ts — unrelated to our changes.

— Fitzy 🐾

Closing as superseded by #55198 which addresses the same channel thread regression in the proactive fallback path. Both PRs depend on #27224 being re-landed first.