Incomplete HTML entity decoding

htmlToPlainText only decodes six named entities ( , &, <, >, ", '). Any other numeric or named HTML entity — e.g.   (non-breaking space), ’ (right single quotation mark), —, é, etc. — will appear as raw literal strings in the extracted quotedSender / quotedBody / cleanBody.

Teams can produce numeric entities in generated HTML (e.g. for curly quotes or special Unicode characters). Consider adding a generic numeric-entity fallback:

.replace(/&#x([0-9a-f]+);/gi, (_, hex) => String.fromCodePoint(parseInt(hex, 16)))
.replace(/&#([0-9]+);/g, (_, dec) => String.fromCodePoint(Number(dec)))

or use a lightweight library like he to handle the full entity spectrum.

This is a comment left during a code review.
Path: extensions/msteams/src/inbound.ts
Line: 67-81

Comment:
**Incomplete HTML entity decoding**

`htmlToPlainText` only decodes six named entities (` `, `&`, `<`, `>`, `"`, `'`). Any other numeric or named HTML entity — e.g. ` ` (non-breaking space), `’` (right single quotation mark), `—`, `é`, etc. — will appear as raw literal strings in the extracted `quotedSender` / `quotedBody` / `cleanBody`.

Teams can produce numeric entities in generated HTML (e.g. for curly quotes or special Unicode characters). Consider adding a generic numeric-entity fallback:

```ts
.replace(/&#x([0-9a-f]+);/gi, (_, hex) => String.fromCodePoint(parseInt(hex, 16)))
.replace(/&#([0-9]+);/g, (_, dec) => String.fromCodePoint(Number(dec)))
```

or use a lightweight library like `he` to handle the full entity spectrum.

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

Quote content duplicated in agent body when HTML lacks post-blockquote text

When the text/html attachment contains only the <blockquote> and no trailing content (e.g. some Teams clients put the new message only in activity.text), htmlToPlainText(afterBlockquote) returns "" and cleanBody falls back to the full fallbackText — the merged flat string that already contains the quoted sender name, the quoted body, and the actual message all concatenated.

In that case agentBody becomes:

Bobsome quotemy actual message

[Replying to Bob]
some quote
[/Replying]

The quotedBody (some quote) appears twice — once buried inside cleanBody and again inside the [Replying to …] block. The agent cannot distinguish the user's actual message from the quoted portion inside cleanBody, so the annotation provides little value in this fallback path.

One approach: when cleanBody === fallbackText, skip emitting the [Replying to …] block (since the structured separation can't be guaranteed anyway), or at least avoid duplicating the annotation:

const agentBody = quoteInfo
  ? quoteInfo.cleanBody !== fallbackText
    ? quoteInfo.cleanBody +
      `\n\n[Replying to ${quoteInfo.quotedSender ?? "unknown"}]\n${quoteInfo.quotedBody ?? "(no text)"}\n[/Replying]`
    : rawBody  // structured extraction failed; surface as-is
  : rawBody;

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

Comment:
**Quote content duplicated in agent body when HTML lacks post-blockquote text**

When the `text/html` attachment contains only the `<blockquote>` and no trailing content (e.g. some Teams clients put the new message only in `activity.text`), `htmlToPlainText(afterBlockquote)` returns `""` and `cleanBody` falls back to the full `fallbackText` — the merged flat string that already contains the quoted sender name, the quoted body, and the actual message all concatenated.

In that case `agentBody` becomes:

```
Bobsome quotemy actual message

[Replying to Bob]
some quote
[/Replying]
```

The `quotedBody` (`some quote`) appears twice — once buried inside `cleanBody` and again inside the `[Replying to …]` block. The agent cannot distinguish the user's actual message from the quoted portion inside `cleanBody`, so the annotation provides little value in this fallback path.

One approach: when `cleanBody === fallbackText`, skip emitting the `[Replying to …]` block (since the structured separation can't be guaranteed anyway), or at least avoid duplicating the annotation:

```ts
const agentBody = quoteInfo
  ? quoteInfo.cleanBody !== fallbackText
    ? quoteInfo.cleanBody +
      `\n\n[Replying to ${quoteInfo.quotedSender ?? "unknown"}]\n${quoteInfo.quotedBody ?? "(no text)"}\n[/Replying]`
    : rawBody  // structured extraction failed; surface as-is
  : rawBody;
```

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

Regex can mis-match on nested or malformed blockquotes

The non-greedy ([\s\S]*?)<\/blockquote> pattern stops at the first </blockquote> it encounters. If Teams ever nests a quoted reply inside another reply (e.g. a thread reply to a reply), or if the blockquote's inner content itself contains a literal </blockquote> string (unlikely but possible in forwarded HTML content), the captured group bqMatch[1] will be truncated and both quotedSender and quotedBody may be wrong or empty.

For the current Teams use-case this is probably fine, but it's worth a brief code comment acknowledging the limitation so future maintainers don't be surprised:

// Note: non-greedy match stops at the first </blockquote>, so nested
// blockquotes are not supported. Teams does not currently produce them
// for quote/reply scenarios.
const blockquoteRe = ...

This is a comment left during a code review.
Path: extensions/msteams/src/inbound.ts
Line: 147-158

Comment:
**Regex can mis-match on nested or malformed blockquotes**

The non-greedy `([\s\S]*?)<\/blockquote>` pattern stops at the **first** `</blockquote>` it encounters. If Teams ever nests a quoted reply inside another reply (e.g. a thread reply to a reply), or if the blockquote's inner content itself contains a literal `</blockquote>` string (unlikely but possible in forwarded HTML content), the captured group `bqMatch[1]` will be truncated and both `quotedSender` and `quotedBody` may be wrong or empty.

For the current Teams use-case this is probably fine, but it's worth a brief code comment acknowledging the limitation so future maintainers don't be surprised:

```ts
// Note: non-greedy match stops at the first </blockquote>, so nested
// blockquotes are not supported. Teams does not currently produce them
// for quote/reply scenarios.
const blockquoteRe = ...
```

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

Avoid treating generic blockquotes as reply metadata

The fallback path matches any <blockquote> when the Skype reply schema is missing, so a normal user-authored quote block in a text/html attachment is reinterpreted as a reply and then rewritten downstream into [Replying to ...] context. This changes message meaning in conversations that use blockquote formatting without using Teams reply UI, because extractMSTeamsQuoteInfo will still return quote data from plain formatting HTML.

Useful? React with 👍 / 👎.

Preserve attachment placeholder in quoted attachment-only messages

When quote info is present, BodyForAgent is always rebuilt from quoteInfo.cleanBody plus the reply annotation and never falls back to rawBody. For quote messages where text is empty and rawBody came from buildMSTeamsAttachmentPlaceholder (for example, attachment-only replies), this drops the placeholder and hides that media/doc content was sent, reducing the agent's available context.

Useful? React with 👍 / 👎.

Guard numeric entity decoding against invalid code points

htmlToPlainText decodes &#x...; / &#...; with String.fromCodePoint(...) directly, which throws RangeError for values above 0x10FFFF (for example �). Because extractMSTeamsQuoteInfo is called on every inbound message before context finalization, a malformed or untrusted HTML attachment can make message handling fail for that turn instead of gracefully treating the entity as plain text.

Useful? React with 👍 / 👎.