DFS stack growth is unbounded despite the DoS protection claim

CARD_MAX_NODES only limits how many nodes are popped and processed; it does not limit how many children are pushed in a single iteration. A single column_set or note element can push an unbounded number of children onto stack before the nodesVisited guard ever runs again.

Concrete attack: a crafted card with column_set.columns containing 10,000 entries each holding 10,000 elements pushes 100 M items to stack in one loop iteration, causing out-of-memory before CARD_MAX_NODES = 500 can protect anything. The card JSON itself would need to be large, but Feishu's per-message size limit (~128 KB) still allows pushing thousands of items per expansion.

Consider adding a hard cap on the number of children pushed per expansion, e.g.:

const MAX_PUSH_PER_EXPANSION = 100; // or tie to CARD_MAX_NODES

if (tag === "note" && Array.isArray(item.elements)) {
  const children = (item.elements as unknown[]).slice(0, MAX_PUSH_PER_EXPANSION);
  for (let i = children.length - 1; i >= 0; i--) {
    stack.push(children[i]);
  }
  continue;
}
if (tag === "column_set" && Array.isArray(item.columns)) {
  const cols = (item.columns as unknown[]).slice(0, MAX_PUSH_PER_EXPANSION);
  for (let ci = cols.length - 1; ci >= 0; ci--) {
    const col = cols[ci] as Record<string, unknown> | undefined;
    if (col && Array.isArray(col.elements)) {
      const els = (col.elements as unknown[]).slice(0, MAX_PUSH_PER_EXPANSION);
      for (let ei = els.length - 1; ei >= 0; ei--) {
        stack.push(els[ei]);
      }
    }
  }
  continue;
}

Or add a stack.length guard at the top of the while loop (e.g. stack.length > CARD_MAX_NODES * 4) to abort before memory is exhausted.

This is a comment left during a code review.
Path: extensions/feishu/src/send.ts
Line: 301-316

Comment:
**DFS stack growth is unbounded despite the DoS protection claim**

`CARD_MAX_NODES` only limits how many nodes are *popped and processed*; it does not limit how many children are *pushed* in a single iteration. A single `column_set` or `note` element can push an unbounded number of children onto `stack` before the `nodesVisited` guard ever runs again.

Concrete attack: a crafted card with `column_set.columns` containing 10,000 entries each holding 10,000 elements pushes 100 M items to `stack` in one loop iteration, causing out-of-memory before `CARD_MAX_NODES = 500` can protect anything. The card JSON itself would need to be large, but Feishu's per-message size limit (~128 KB) still allows pushing thousands of items per expansion.

Consider adding a hard cap on the number of children pushed per expansion, e.g.:

```ts
const MAX_PUSH_PER_EXPANSION = 100; // or tie to CARD_MAX_NODES

if (tag === "note" && Array.isArray(item.elements)) {
  const children = (item.elements as unknown[]).slice(0, MAX_PUSH_PER_EXPANSION);
  for (let i = children.length - 1; i >= 0; i--) {
    stack.push(children[i]);
  }
  continue;
}
if (tag === "column_set" && Array.isArray(item.columns)) {
  const cols = (item.columns as unknown[]).slice(0, MAX_PUSH_PER_EXPANSION);
  for (let ci = cols.length - 1; ci >= 0; ci--) {
    const col = cols[ci] as Record<string, unknown> | undefined;
    if (col && Array.isArray(col.elements)) {
      const els = (col.elements as unknown[]).slice(0, MAX_PUSH_PER_EXPANSION);
      for (let ei = els.length - 1; ei >= 0; ei--) {
        stack.push(els[ei]);
      }
    }
  }
  continue;
}
```

Or add a `stack.length` guard at the top of the while loop (e.g. `stack.length > CARD_MAX_NODES * 4`) to abort before memory is exhausted.

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

Misleading constant name

CARD_MAX_QUEUED_ARRAYS is used as a limit on the number of paragraphs iterated in the legacy rich-text path — not on anything actually "queued". The name implies it bounds a queue/stack, which can mislead a future reader into thinking the legacy path is already stack-guarded. Consider renaming to CARD_MAX_PARAGRAPHS or CARD_LEGACY_MAX_PARAGRAPHS to match what the variable actually controls.

This is a comment left during a code review.
Path: extensions/feishu/src/send.ts
Line: 149-151

Comment:
**Misleading constant name**

`CARD_MAX_QUEUED_ARRAYS` is used as a limit on the number of *paragraphs* iterated in the legacy rich-text path — not on anything actually "queued". The name implies it bounds a queue/stack, which can mislead a future reader into thinking the legacy path is already stack-guarded. Consider renaming to `CARD_MAX_PARAGRAPHS` or `CARD_LEGACY_MAX_PARAGRAPHS` to match what the variable actually controls.

```suggestion
const CARD_MAX_NODES = 500;
const CARD_MAX_OUTPUT_CHARS = 8000;
const CARD_MAX_PARAGRAPHS = 64;
```

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

Apply node limits before queuing all card elements

The CARD_MAX_NODES guard is only enforced in the DFS while condition, but this loop pre-queues every entry from elementSources first, so a card with an extremely large body.elements array will still force O(n) pushes and memory growth before the 500-node limit can help. Because schema 2.0 cards are newly traversed in this change, this introduces a new path where attacker-controlled interactive-card payloads can still trigger high CPU/memory usage despite the intended bound.

Useful? React with 👍 / 👎.

Clamp fragment length before appending card text

The output cap is checked before appending, but each fragment is appended in full and only then counted, so one oversized markdown/plain_text field can exceed CARD_MAX_OUTPUT_CHARS by a large margin. In large-card scenarios this returns far more text than intended to downstream processing and defeats the protection implied by the size limit.

Useful? React with 👍 / 👎.

Cap legacy inline traversal independently of extracted chars

The loop over legacy card.content inlines only stops when totalChars >= maxChars, so cards with very large paragraphs of unsupported inline nodes (for example many img/unknown tags) are still scanned in full because totalChars never increases. This keeps an attacker-controlled O(n) CPU path in quoted interactive-card parsing even after adding bounds, so extractLegacyContentText needs a node/iteration limit similar to CARD_MAX_NODES.

Useful? React with 👍 / 👎.

Apply output cap before appending top-level card title

card.title is appended without checking CARD_MAX_OUTPUT_CHARS, so a single oversized title can bypass the intended 8k output bound before any other extraction logic runs. In that case parseInteractiveCardContent can still return arbitrarily large text to downstream processing despite the new size guard.

Useful? React with 👍 / 👎.

Enforce push limits while expanding column_set children

In parseInteractiveCardContent, this column_set branch pushes every nested element onto stack without checking remaining node/stack budget, and the stackSizeLimit guard runs only on the next while iteration. A single interactive card with a very large columns[*].elements payload can therefore still force O(n) stack growth and high memory/CPU before the limit is applied, which undermines the DoS protection added in this commit.

Useful? React with 👍 / 👎.

Clamp legacy inline fragments to the output budget

extractLegacyContentText adds each extracted legacy inline string in full and only checks totalChars >= maxChars before the next node, so one oversized text/a/code_block fragment can exceed CARD_MAX_OUTPUT_CHARS by a large margin. This means interactive legacy cards can still return much more content than intended and negate the new output cap in large-fragment scenarios.

Useful? React with 👍 / 👎.

Count every legacy content entry toward paragraph budget

In extractLegacyContentText, the paragraph budget is only incremented after Array.isArray(paragraph) passes, so a malformed content array with many non-array entries is scanned end-to-end with no top-level cap. This legacy-card path is new in this commit, so a crafted interactive payload can still force O(n) parsing work despite the added DoS bounds; consume budget before the type guard so all entries are bounded.

Useful? React with 👍 / 👎.

Fallback to mention IDs when user_name is absent

Legacy at nodes are only rendered when user_name is present, so mentions that provide only user_id/open_id are dropped from extracted card text. That loses important participant context in quoted interactive cards and can degrade reply accuracy; use ID fields as a fallback when user_name is missing.

Useful? React with 👍 / 👎.

Count newline separators in card output budget

The new CARD_MAX_OUTPUT_CHARS guard only tracks fragment text length, but the final output is built with texts.join("\n"), which adds one extra character between every fragment that is never budgeted. In cards with many small fragments (for example lots of short plain_text or legacy inline nodes), this can exceed the intended 8k cap by hundreds to ~1.5k characters, weakening the DoS bound this change introduces.

Useful? React with 👍 / 👎.

Strip carriage returns in card text sanitization

sanitizeCardText removes ESC and most control characters but still allows \r, so the newly parsed interactive-card fields can carry carriage returns into quotedMsg.content; that value is logged directly in extensions/feishu/src/bot.ts (fetched quoted message: ...), which allows crafted quoted cards to forge or overwrite log lines despite the CWE-117 hardening in this commit. Normalize or strip \r (for example by converting CRLF to \n) before returning sanitized card text.

Useful? React with 👍 / 👎.

Parse top-level card headers

This extraction path only checks card.title and then traverses elements/body.elements, but standard Feishu card titles are typically under card.header.title.content, so cards with header-only text (or headers plus non-text body blocks) still lose their primary context and can fall back to [Interactive Card]. This means the new header support is incomplete for real interactive payloads and quoted-message understanding remains degraded in those cases.

Useful? React with 👍 / 👎.

Preserve core registration path for default context engine

registerContextEngine() now always registers with owner "public-sdk", so registerLegacyContextEngine() (which still calls this API with id "legacy") is rejected by the new default-slot owner check and silently leaves the default engine unregistered. Any normal agent run that calls ensureContextEnginesInitialized() and then resolveContextEngine() can now fail with Context engine "legacy" is not registered, which is a functional regression in the main runtime path.

Useful? React with 👍 / 👎.