Greptile Summary

This PR fixes a session-lock bug in FeishuStreamingSession: when start() throws (e.g. HTTP 400 from the CardKit v1 API), the catch block previously nulled streaming but left streamingStartPromise pointing to the resolved IIFE. Because startStreaming() guards on streamingStartPromise first, all subsequent deliver() calls would skip streaming silently and all future messages would be dropped for the lifetime of the dispatcher.

The fix is a single-line addition — streamingStartPromise = null in the same catch block — which correctly unblocks the guard and allows the next deliver() call to retry streaming. A targeted regression test validates the full recovery path.

Key changes:

• extensions/feishu/src/reply-dispatcher.ts: Clear streamingStartPromise in the start() catch block alongside streaming, allowing the session to retry on the next delivery.
• extensions/feishu/src/reply-dispatcher.test.ts: New test intercepts streamingInstances.push to inject a rejecting start() on the first session, then verifies that a second deliver() successfully creates and closes a fresh streaming session. The streamingInstances.push override is restored sequentially in the test body rather than inside a finally block — if an assertion fails before the restore line, the override persists (though it is practically harmless because shouldFailStart is already false).
• CHANGELOG.md: Entry added under the current release.

Confidence Score: 5/5

• This PR is safe to merge — the fix is a minimal, targeted one-liner with a direct regression test and no side effects on the surrounding control flow.
• The change touches a single catch block, clears a variable that was already being cleared in closeStreaming, and the concurrent-await semantics are correct (callers holding a reference to the IIFE promise still resolve cleanly). The regression test covers the exact failure scenario. No unrelated code is modified.
• No files require special attention beyond the minor test-cleanup hygiene noted in reply-dispatcher.test.ts.

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

Comment:
**Push override not restored in `finally` block**

The `streamingInstances.push` restore is executed sequentially in the test body after the assertions. If any assertion before line 629 fails (e.g. `expect(streamingInstances).toHaveLength(2)` on line 632), the override is never cleaned up and persists into subsequent tests.

`beforeEach` resets `streamingInstances.length = 0` but does not reset `streamingInstances.push`, so the override would carry over. In practice it is mostly harmless because `shouldFailStart` is `false` by that point (making the override a no-op passthrough to `origPush`), but it is not idiomatic and could mask subtle issues if the test suite is extended.

Consider wrapping the test body with a `try/finally`:

```ts
    const origPush = streamingInstances.push;
    try {
      streamingInstances.push = function (this: any[], ...args: any[]) {
        if (shouldFailStart) {
          args[0].start = vi
            .fn()
            .mockRejectedValue(new Error("Create card request failed with HTTP 400"));
          shouldFailStart = false;
        }
        return origPush.apply(this, args);
      } as any;

      // ... test body ...

    } finally {
      streamingInstances.push = origPush;
    }
```

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

_{Last reviewed commit: 6cf243a}

Re: Aisle (CWE-400 unbounded retry)

The prior behaviour was a permanent session lock - zero retries, ever. Once start() failed, every future message was silently dropped for the rest of the session (13+ hours in the reported case). Clearing streamingStartPromise allows one retry per deliver() call, which is strictly better than permanent failure. A bounded retry or circuit breaker could be reasonable follow-up work but sits outside this bug fix's scope.

Re: Greptile (5/5)

Cheers for the thorough analysis. The partialUpdateQueue safety point re: lazy reference reads is spot on - closeStreaming() already had the same streamingStartPromise = null cleanup, so this just mirrors it in the failure path.

Rebased onto latest main. CHANGELOG entry verified. All code checks, extensions, and protocol pass. The node test shard and Windows shard failures are from the temp-path-guard.test.ts regression on main (da1ec45505) - same failures on every open PR in the repo, including PRs that maintainers are actively merging.