Fallback to text send when streaming start fails

If streaming.start() fails (for example due to bad app credentials or a transient Feishu API error), this branch still stores the final payload and returns early. onIdle then follows the streaming-card path and only calls closeStreaming(), so no non-stream message is ever sent and the user can get no final reply at all. We should preserve the previous fallback behavior and send chunked text when streaming is not active.

Useful? React with 👍 / 👎.

Await typing startup before continuing dispatch

Calling typingCallbacks.onReplyStart with void introduces a race on fast responses: onIdle can run before addTypingIndicator finishes, so stop() sees no typingState and does nothing, then the start promise resolves and leaves a stale typing reaction with no later cleanup. Awaiting onReplyStart avoids this indicator leak and restores the prior ordering guarantees.

Useful? React with 👍 / 👎.

Silent content drop when streaming fails to start

When streamingEnabled && useCard is true but streaming is null (e.g., the startStreaming() call failed with a network/API error), this branch calls closeStreaming() — which is a no-op since streaming is already null — and then adds text to deliveredFinalTexts without ever sending it to the user.

The original code handled this via a fallback: after the if (streaming?.isActive()) early-return block in deliver, the code fell through to sendStructuredCardFeishu/sendMessageFeishu when streaming was null. The new deferred-final approach moves all delivery to onIdle but only provides a send-fallback in the else branch (i.e., when !streamingEnabled || !useCard), leaving the failure case uncovered.

A minimal fix is to check streaming before deciding whether to close or send directly:

if (hasText) {
  if (streamingEnabled && useCard) {
    if (streaming?.isActive()) {
      streamText = mergeStreamingText(streamText, text);
      await closeStreaming();
    } else {
      // Streaming failed to start — fall back to a direct card send
      await sendChunkedTextReply({ text, useCard: true, infoKind: "final" });
    }
    deliveredFinalTexts.add(text);
  } else {
    await sendChunkedTextReply({ text, useCard, infoKind: "final" });
    deliveredFinalTexts.add(text);
  }
}

This is a comment left during a code review.
Path: extensions/feishu/src/reply-dispatcher.ts
Line: 413-424

Comment:
**Silent content drop when streaming fails to start**

When `streamingEnabled && useCard` is true but `streaming` is `null` (e.g., the `startStreaming()` call failed with a network/API error), this branch calls `closeStreaming()` — which is a no-op since `streaming` is already `null` — and then adds `text` to `deliveredFinalTexts` without ever sending it to the user.

The original code handled this via a fallback: after the `if (streaming?.isActive())` early-return block in `deliver`, the code fell through to `sendStructuredCardFeishu`/`sendMessageFeishu` when `streaming` was null. The new deferred-final approach moves all delivery to `onIdle` but only provides a send-fallback in the `else` branch (i.e., when `!streamingEnabled || !useCard`), leaving the failure case uncovered.

A minimal fix is to check `streaming` before deciding whether to close or send directly:

```typescript
if (hasText) {
  if (streamingEnabled && useCard) {
    if (streaming?.isActive()) {
      streamText = mergeStreamingText(streamText, text);
      await closeStreaming();
    } else {
      // Streaming failed to start — fall back to a direct card send
      await sendChunkedTextReply({ text, useCard: true, infoKind: "final" });
    }
    deliveredFinalTexts.add(text);
  } else {
    await sendChunkedTextReply({ text, useCard, infoKind: "final" });
    deliveredFinalTexts.add(text);
  }
}
```

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

streamingStartPromise not cleared on error — blocks all subsequent streaming attempts

The old code reset streamingStartPromise = null in the catch block specifically so that the next deliver call could retry streaming. That reset was removed in this PR.

startStreaming() guards itself with:

if (!streamingEnabled || streamingStartPromise || streaming) {
  return;
}

After the error, streaming is null but streamingStartPromise still points to a resolved (caught) Promise, so every subsequent call to startStreaming() silently returns early. For the rest of the response lifecycle, no new streaming session can be established.

Combined with the deferred-final design (content only sent in onIdle), this directly amplifies the silent-drop bug above: a transient start() failure guarantees that the pending final text is never delivered.

This is a comment left during a code review.
Path: extensions/feishu/src/reply-dispatcher.ts
Line: 207-210

Comment:
**`streamingStartPromise` not cleared on error — blocks all subsequent streaming attempts**

The old code reset `streamingStartPromise = null` in the catch block specifically so that the next `deliver` call could retry streaming. That reset was removed in this PR.

`startStreaming()` guards itself with:
```typescript
if (!streamingEnabled || streamingStartPromise || streaming) {
  return;
}
```

After the error, `streaming` is `null` but `streamingStartPromise` still points to a **resolved** (caught) Promise, so every subsequent call to `startStreaming()` silently returns early. For the rest of the response lifecycle, no new streaming session can be established.

Combined with the deferred-final design (content only sent in `onIdle`), this directly amplifies the silent-drop bug above: a transient `start()` failure guarantees that the pending final text is never delivered.

```suggestion
        params.runtime.error?.(`feishu: streaming start failed: ${String(error)}`);
        streaming = null;
        streamingStartPromise = null; // allow retry on next deliver
```

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

pendingFinalPayload not flushed on error

The PR description acknowledges this explicitly, but it's worth calling out for reviewers: if onError fires before onIdle (e.g., the agent errors mid-run after stashing a final payload), pendingFinalPayload is not consumed. The user would see the streaming card closed (via closeStreaming()) but would receive no final message text.

A simple mitigation is to attempt to flush the pending payload in onError before closing the stream:

onError: async (error, info) => {
  params.runtime.error?.(
    `feishu[${account.accountId}] ${info.kind} reply failed: ${String(error)}`,
  );
  // Flush deferred final if it hasn't been sent yet
  if (pendingFinalPayload) {
    const text = pendingFinalPayload.text ?? "";
    streamText = mergeStreamingText(streamText, text);
    pendingFinalPayload = null;
    pendingFinalMediaList = [];
  }
  await closeStreaming();
  typingCallbacks.onIdle?.();
},

This is a follow-up candidate the PR author flagged — flagging here so it doesn't get lost.

This is a comment left during a code review.
Path: extensions/feishu/src/reply-dispatcher.ts
Line: 394-399

Comment:
**`pendingFinalPayload` not flushed on error**

The PR description acknowledges this explicitly, but it's worth calling out for reviewers: if `onError` fires before `onIdle` (e.g., the agent errors mid-run after stashing a final payload), `pendingFinalPayload` is not consumed. The user would see the streaming card closed (via `closeStreaming()`) but would receive no final message text.

A simple mitigation is to attempt to flush the pending payload in `onError` before closing the stream:
```typescript
onError: async (error, info) => {
  params.runtime.error?.(
    `feishu[${account.accountId}] ${info.kind} reply failed: ${String(error)}`,
  );
  // Flush deferred final if it hasn't been sent yet
  if (pendingFinalPayload) {
    const text = pendingFinalPayload.text ?? "";
    streamText = mergeStreamingText(streamText, text);
    pendingFinalPayload = null;
    pendingFinalMediaList = [];
  }
  await closeStreaming();
  typingCallbacks.onIdle?.();
},
```
This is a follow-up candidate the PR author flagged — flagging here so it doesn't get lost.

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

createTypingCallbacks is imported from openclaw/plugin-sdk/feishu, but that subpath does not currently export it (src/plugin-sdk/feishu.ts has no such export). This will fail to compile unless the export is added or the import is changed back to createChannelReplyPipeline/another exported helper.

In startStreaming() the catch block nulls streaming but leaves streamingStartPromise set. Because startStreaming() bails out when streamingStartPromise is truthy, a single start failure will permanently prevent future streaming retries for the lifetime of this dispatcher. Reset streamingStartPromise (and/or clear streaming) on failure so later delivers can retry.

Streaming card start no longer passes header/note options, even though FeishuStreamingSession.start() supports them (and previous behavior/tests rely on them for agent identity + model/provider context). This is a user-visible regression and also contradicts the PR description (“all other paths unchanged”). Either restore header/note generation/passing or update the PR scope + tests accordingly.

The final branch updates the streaming card via direct await streaming.update(...) calls instead of going through partialUpdateQueue (used by queueStreamingUpdate). This can cause concurrent/out-of-order update requests relative to queued partial/block updates. Consider routing these updates through the same queue to guarantee serialized updates to the Feishu API.

All final payloads are deferred to onIdle even when streaming is disabled. That changes the delivery contract (deliver() no longer sends the final immediately), and if onIdle is not reached (e.g. error path), the final can be dropped. If the intent is only to suppress duplicate finals for streaming card mode, consider limiting deferral to that case, or ensure deferred finals are flushed in onError as well.

onError closes the streaming card but does not flush pendingFinalPayload. If an error occurs after a thinking model has emitted a deferred final, the user may receive no final message at all. Consider flushing the pending final (best-effort) in onError before/after closeStreaming().

replyOptions no longer provides onReasoningStream / onReasoningEnd when streaming is enabled. Existing Feishu behavior/tests expect reasoning to be streamed into the card, and the PR description claims reasoning/block/partial paths are unchanged. Either restore the reasoning callbacks (and formatting) or update the PR description + tests to reflect the new behavior.