openclaw#24969)

Block payloads (info.kind === "block") contain reasoning/thinking content
that should only be visible in the internal web UI. When streamMode is
"partial", these blocks were being delivered to Discord as visible
messages, leaking chain-of-thought to end users.

Add an early return for block payloads in the deliver callback,
consistent with the WhatsApp fix and Telegram's existing behavior.

Fixes openclaw#24532

Co-authored-by: Cursor <cursoragent@cursor.com>

When blockStreaming is enabled, normal replies are delivered via
sendBlockReply (info.kind === 'block'). The previous fix for openclaw#24969
blindly suppressed ALL block payloads, causing normal replies to be
silently dropped when blockStreaming is true.

Fix: only suppress block payloads tagged with isReasoning=true,
which are actual reasoning/thinking blocks that should not leak
to end users.

Fixes regression introduced by 38da3f4.

When blockStreaming is enabled, normal replies are delivered via
sendBlockReply (info.kind === 'block'). The previous fix for openclaw#24969
blindly suppressed ALL block payloads, causing normal replies to be
silently dropped when blockStreaming is true.

Fix: only suppress block payloads tagged with isReasoning=true,
which are actual reasoning/thinking blocks that should not leak
to end users.

Fixes regression introduced by 38da3f4.

When blockStreaming is enabled, normal replies are delivered via
sendBlockReply (info.kind === 'block'). The previous fix for openclaw#24969
blindly suppressed ALL block payloads, causing normal replies to be
silently dropped when blockStreaming is true.

Fix: only suppress block payloads tagged with isReasoning=true,
which are actual reasoning/thinking blocks that should not leak
to end users.

Fixes regression introduced by 38da3f4.

openclaw#24969)

Block payloads (info.kind === "block") contain reasoning/thinking content
that should only be visible in the internal web UI. When streamMode is
"partial", these blocks were being delivered to Discord as visible
messages, leaking chain-of-thought to end users.

Add an early return for block payloads in the deliver callback,
consistent with the WhatsApp fix and Telegram's existing behavior.

Fixes openclaw#24532

Co-authored-by: Cursor <cursoragent@cursor.com>

When blockStreaming is enabled, normal replies are delivered via
sendBlockReply (info.kind === 'block'). The previous fix for openclaw#24969
blindly suppressed ALL block payloads, causing normal replies to be
silently dropped when blockStreaming is true.

Fix: only suppress block payloads tagged with isReasoning=true,
which are actual reasoning/thinking blocks that should not leak
to end users.

Fixes regression introduced by 38da3f4.

openclaw#24969 introduced an early return for all `info.kind === "block"`
payloads in the Discord deliver callback, intending to suppress
reasoning/thinking content. However, block payloads are the primary
delivery mechanism when `blockStreaming: true` — this broke all
streamed text responses to Discord.

Use the `isReasoning` flag (added in 7d76c24) instead, which
correctly targets only reasoning content.

Fixes openclaw#25836

openclaw#24969 introduced an early return for all `info.kind === "block"`
payloads in the Discord deliver callback, intending to suppress
reasoning/thinking content. However, block payloads are the primary
delivery mechanism when `blockStreaming: true` — this broke all
streamed text responses to Discord.

Use the `isReasoning` flag (added in 7d76c24) instead, which
correctly targets only reasoning content. Update the corresponding
test to set `isReasoning: true` on the fixture payload.

Fixes openclaw#25836

openclaw#24969 introduced an early return for all `info.kind === "block"`
payloads in the Discord deliver callback, intending to suppress
reasoning/thinking content. However, block payloads are the primary
delivery mechanism when `blockStreaming: true` — this broke all
streamed text responses to Discord.

Use the `isReasoning` flag (added in 7d76c24) instead, which
correctly targets only reasoning content. Update the corresponding
test to set `isReasoning: true` on the fixture payload.

Fixes openclaw#25836

openclaw#24969)

Block payloads (info.kind === "block") contain reasoning/thinking content
that should only be visible in the internal web UI. When streamMode is
"partial", these blocks were being delivered to Discord as visible
messages, leaking chain-of-thought to end users.

Add an early return for block payloads in the deliver callback,
consistent with the WhatsApp fix and Telegram's existing behavior.

Fixes openclaw#24532

Co-authored-by: Cursor <cursoragent@cursor.com>
(cherry picked from commit 38da3f4)

openclaw#24969)

Block payloads (info.kind === "block") contain reasoning/thinking content
that should only be visible in the internal web UI. When streamMode is
"partial", these blocks were being delivered to Discord as visible
messages, leaking chain-of-thought to end users.

Add an early return for block payloads in the deliver callback,
consistent with the WhatsApp fix and Telegram's existing behavior.

Fixes openclaw#24532

Co-authored-by: Cursor <cursoragent@cursor.com>

openclaw#24969)

Block payloads (info.kind === "block") contain reasoning/thinking content
that should only be visible in the internal web UI. When streamMode is
"partial", these blocks were being delivered to Discord as visible
messages, leaking chain-of-thought to end users.

Add an early return for block payloads in the deliver callback,
consistent with the WhatsApp fix and Telegram's existing behavior.

Fixes openclaw#24532

Co-authored-by: Cursor <cursoragent@cursor.com>

openclaw#24969)

Block payloads (info.kind === "block") contain reasoning/thinking content
that should only be visible in the internal web UI. When streamMode is
"partial", these blocks were being delivered to Discord as visible
messages, leaking chain-of-thought to end users.

Add an early return for block payloads in the deliver callback,
consistent with the WhatsApp fix and Telegram's existing behavior.

Fixes openclaw#24532

Co-authored-by: Cursor <cursoragent@cursor.com>

openclaw#24969)

Block payloads (info.kind === "block") contain reasoning/thinking content
that should only be visible in the internal web UI. When streamMode is
"partial", these blocks were being delivered to Discord as visible
messages, leaking chain-of-thought to end users.

Add an early return for block payloads in the deliver callback,
consistent with the WhatsApp fix and Telegram's existing behavior.

Fixes openclaw#24532

Co-authored-by: Cursor <cursoragent@cursor.com>

…check / data leak

Pattern from PR openclaw#24969

The revised proposal addresses the validation feedback by ensuring the privacy guard for `info.kind === 'block'` is placed strictly at the top of the function (addressing the flow concern), maintains the original variable declaration order to prevent ReferenceErrors (addressing the side effect concern), and includes a specific unit test for the 'block' scenario (addressing the testing concern). The fix logic explicitly filters out 'block' payloads before any logic related to draft streaming, media handling, or final text processing can execute.

… / data leak

Pattern from PR openclaw#24969

The fix addresses the critical race condition by placing the 'block' filter check at the very top of the `deliver` function. This ensures that for internal 'block' reasoning chunks, the function returns immediately, preventing any text processing (lines 195-203) and, crucially, preventing the initialization of the streaming state for these payloads (lines 212-216). This ensures that the `streaming` object is not initialized with empty data, and subsequent 'final' payloads will correctly initialize and stream only the final content. The fix also addresses the 'incomplete' validation issue by using `info?.kind !== 'block'`. While the contract likely ensures `info` is present, this defensive approach ensures that if `info` is missing (and the payload is unrelated to internal blocking), the message is still delivered to the user, preventing a 'silent failure' bug. The validation logic at line 205 (`!hasText && !hasMedia`) ensures we do not send empty messages.

…#31723)

* fix(extensions/feishu/src/reply-dispatcher.ts): missing privacy check / data leak

Pattern from PR #24969

The fix addresses the critical race condition by placing the 'block' filter check at the very top of the `deliver` function. This ensures that for internal 'block' reasoning chunks, the function returns immediately, preventing any text processing (lines 195-203) and, crucially, preventing the initialization of the streaming state for these payloads (lines 212-216). This ensures that the `streaming` object is not initialized with empty data, and subsequent 'final' payloads will correctly initialize and stream only the final content. The fix also addresses the 'incomplete' validation issue by using `info?.kind !== 'block'`. While the contract likely ensures `info` is present, this defensive approach ensures that if `info` is missing (and the payload is unrelated to internal blocking), the message is still delivered to the user, preventing a 'silent failure' bug. The validation logic at line 205 (`!hasText && !hasMedia`) ensures we do not send empty messages.

* Fix indentation: remove extra 4 spaces from deliver function body

The deliver function is inside the createReplyDispatcherWithTyping call,
so it should be indented at 2 levels (8 spaces), not 3 levels (12 spaces).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* test(feishu): cover block payload suppression in reply dispatcher

---------

Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: Tak Hoffman <781889+Takhoffman@users.noreply.github.com>

…openclaw#31723)

* fix(extensions/feishu/src/reply-dispatcher.ts): missing privacy check / data leak

Pattern from PR openclaw#24969

The fix addresses the critical race condition by placing the 'block' filter check at the very top of the `deliver` function. This ensures that for internal 'block' reasoning chunks, the function returns immediately, preventing any text processing (lines 195-203) and, crucially, preventing the initialization of the streaming state for these payloads (lines 212-216). This ensures that the `streaming` object is not initialized with empty data, and subsequent 'final' payloads will correctly initialize and stream only the final content. The fix also addresses the 'incomplete' validation issue by using `info?.kind !== 'block'`. While the contract likely ensures `info` is present, this defensive approach ensures that if `info` is missing (and the payload is unrelated to internal blocking), the message is still delivered to the user, preventing a 'silent failure' bug. The validation logic at line 205 (`!hasText && !hasMedia`) ensures we do not send empty messages.

* Fix indentation: remove extra 4 spaces from deliver function body

The deliver function is inside the createReplyDispatcherWithTyping call,
so it should be indented at 2 levels (8 spaces), not 3 levels (12 spaces).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* test(feishu): cover block payload suppression in reply dispatcher

---------

Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: Tak Hoffman <781889+Takhoffman@users.noreply.github.com>

…openclaw#31723)

* fix(extensions/feishu/src/reply-dispatcher.ts): missing privacy check / data leak

Pattern from PR openclaw#24969

The fix addresses the critical race condition by placing the 'block' filter check at the very top of the `deliver` function. This ensures that for internal 'block' reasoning chunks, the function returns immediately, preventing any text processing (lines 195-203) and, crucially, preventing the initialization of the streaming state for these payloads (lines 212-216). This ensures that the `streaming` object is not initialized with empty data, and subsequent 'final' payloads will correctly initialize and stream only the final content. The fix also addresses the 'incomplete' validation issue by using `info?.kind !== 'block'`. While the contract likely ensures `info` is present, this defensive approach ensures that if `info` is missing (and the payload is unrelated to internal blocking), the message is still delivered to the user, preventing a 'silent failure' bug. The validation logic at line 205 (`!hasText && !hasMedia`) ensures we do not send empty messages.

* Fix indentation: remove extra 4 spaces from deliver function body

The deliver function is inside the createReplyDispatcherWithTyping call,
so it should be indented at 2 levels (8 spaces), not 3 levels (12 spaces).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* test(feishu): cover block payload suppression in reply dispatcher

---------

Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: Tak Hoffman <781889+Takhoffman@users.noreply.github.com>

openclaw#24969)

Block payloads (info.kind === "block") contain reasoning/thinking content
that should only be visible in the internal web UI. When streamMode is
"partial", these blocks were being delivered to Discord as visible
messages, leaking chain-of-thought to end users.

Add an early return for block payloads in the deliver callback,
consistent with the WhatsApp fix and Telegram's existing behavior.

Fixes openclaw#24532

Co-authored-by: Cursor <cursoragent@cursor.com>

…openclaw#31723)

* fix(extensions/feishu/src/reply-dispatcher.ts): missing privacy check / data leak

Pattern from PR openclaw#24969

The fix addresses the critical race condition by placing the 'block' filter check at the very top of the `deliver` function. This ensures that for internal 'block' reasoning chunks, the function returns immediately, preventing any text processing (lines 195-203) and, crucially, preventing the initialization of the streaming state for these payloads (lines 212-216). This ensures that the `streaming` object is not initialized with empty data, and subsequent 'final' payloads will correctly initialize and stream only the final content. The fix also addresses the 'incomplete' validation issue by using `info?.kind !== 'block'`. While the contract likely ensures `info` is present, this defensive approach ensures that if `info` is missing (and the payload is unrelated to internal blocking), the message is still delivered to the user, preventing a 'silent failure' bug. The validation logic at line 205 (`!hasText && !hasMedia`) ensures we do not send empty messages.

* Fix indentation: remove extra 4 spaces from deliver function body

The deliver function is inside the createReplyDispatcherWithTyping call,
so it should be indented at 2 levels (8 spaces), not 3 levels (12 spaces).


* test(feishu): cover block payload suppression in reply dispatcher

---------

Co-authored-by: Tak Hoffman <781889+Takhoffman@users.noreply.github.com>