Problem

When using Feishu (飞书) as the chat channel, long AI responses produce two streaming cards instead of one. Short single-stream responses work fine, but any response that triggers multiple stream blocks + final delivery always creates a duplicate card.

Root Cause

The issue is in the Feishu integration's streaming card logic at extensions/feishu/src/monitor-DDkD5r4p.js in createFeishuReplyDispatcher.

In the deliver(final) path:

1. If streaming is active, it calls closeStreaming() which destroys the current streaming card
2. Then adds the final text to deliveredFinalTexts
3. On the next reply, the final text is NOT in deliveredFinalTexts, so a new card is created

Additionally, the 100ms throttle in queueStreamingUpdate causes content truncation on long responses, hitting a fallback path that also creates a second card.

Related Issues

• [Feishu] Card streaming creates duplicate card on every response (counts.final=2) #62059 — Two streaming cards per response
• Feishu streaming card produces duplicate/truncated messages with long replies #65993 — 100ms throttling causes duplicates
• Feishu Channel: Duplicate streaming cards due to state management race condition in reply-dispatcher.ts #46135 / Feishu: duplicate card delivery for long streaming responses #43612 — Related issues
• PR fix(feishu): prevent streaming card duplication on multi-final replies #42940 — Reference fix approach

Suggested Fix

Replace the closeStreaming() call in the final branch with queueStreamingUpdate(text, { mode: "snapshot" }):

  if (info?.kind === "final") {
    streamText = mergeStreamingText(streamText, text);
-   await closeStreaming();
-   deliveredFinalTexts.add(text);
+   queueStreamingUpdate(text, { mode: "snapshot" });
  }

Why: snapshot mode refreshes the streaming card content in-place and keeps the card alive, instead of closing and recreating it. The subsequent onIdle handler will close the card naturally, preventing duplicates.

Additional Notes

Adjusting channels.feishu.blockStreamingCoalesce from the default 50/200ms to 500/2000ms reduces truncation risk on long responses.

This patch is applied locally and needs re-application after each OpenClaw update.