fix(auto-reply): gate sendBlockReply on disableBlockStreaming

[reason-bot]

Summary

Fixes the inter-tool block-payload leak on channels that set channels.<provider>.streaming.block.enabled = false (Slack in our case; class of bug tracked upstream as openclaw/openclaw#25592 — canonical, currently P1, impact:message-loss, clawsweeper:linked-pr-open).

Behavior before this patch: one agent turn producing N text blocks between tool calls resulted in N separate chat.postMessage calls to Slack. replyPlan.nextThreadTs() returns a threadTs only for the first payload, so payloads 2..N post as top-level channel messages — hence the "one clean reply in-thread, then a rapid burst of unrelated-looking channel-root posts" pattern.

After this patch: those inter-tool text blocks are dropped at the dispatcher. Tool results and the final reply still flow. Durable reasoning/commentary lanes (which have their own opt-in via reasoningPayloadsEnabled / commentaryPayloadsEnabled) are untouched.

Root cause

disableBlockStreaming: true (produced by resolving channels.slack.streaming.block.enabled: false) is threaded through replyOptions and correctly disables the streamed block-reply pipeline in agent-runner.runtime. It does not disable the plain block-delivery path:

• dispatch-from-config.ts's onBlockReply handler fires on every assistant text block between tool calls; its exit gates cover suppressDelivery, reasoning/commentary channel opt-ins, and empty text, but not disableBlockStreaming.
• The handler ends by calling dispatcher.sendBlockReply(normalizedPayload).
• sendBlockReply in reply-dispatcher.ts is enqueue("block", payload) with no gate — it drives one deliver() per payload with a ~130ms inter-block human-delay sleep (matching the observed cadence in logs).

Runtime designers assumed "if block streaming is off, upstream won't emit block payloads at all," but the emission path in dispatch-from-config.ts was never wired to that flag. Two consumers of disableBlockStreaming, one honored, one not.

The fix (defense in depth)

1. src/auto-reply/reply/reply-dispatcher.ts — Add disableBlockStreaming?: boolean to ReplyDispatcherOptions. sendBlockReply returns false (matching the existing normalization-skip return contract) when set. sendToolResult and sendFinalReply are unchanged.

2. src/auto-reply/reply/dispatch-from-config.ts — Early-return in the runtime's onBlockReply handler when params.replyOptions?.disableBlockStreaming === true and the payload isn't a durable reasoning/commentary lane. Placed after the reasoning/commentary channel-owned-lane checks so those keep their existing opt-in semantics. Avoids the normalize/TTS/accumulate work for a payload we're about to drop.

3. src/auto-reply/dispatch.ts — Hoist disableBlockStreaming from incoming replyOptions into the dispatcher options in both dispatchInboundMessageWithBufferedDispatcher and dispatchInboundMessageWithDispatcher, so channels that only set it on replyOptions (Slack does) get the dispatcher-level gate too. Channel-provided dispatcherOptions.disableBlockStreaming takes precedence when both are set.

4. src/auto-reply/reply/reply-dispatcher.disable-block-streaming.test.ts (new) — Three focused unit tests: drops block replies when enabled, passes through when unset, passes through when explicitly false. Asserts tool + final still flow, and that drops don't count as cancellations (they were never enqueued).

Belt-and-suspenders on purpose. Either gate is sufficient in isolation; both together cover future direct-emit paths that might bypass one layer or the other.

Verification

Run in the local checkout at ~/code/openclaw:

• vitest.auto-reply-reply project — 2,597 tests pass (136 files), including 3 new + existing dispatcher / dispatch-from-config suites.
• vitest.auto-reply-core — 418 tests pass.
• vitest.auto-reply-top-level — 11 tests pass.
• tsgo -p tsconfig.core.json --noEmit — clean.
• Runtime at /opt/homebrew/lib/node_modules/openclaw/dist/ was not touched (SHA-verified pre- and post-diagnosis).

Prior art / not covered by

Searched issues + PRs (open and closed) before writing this:

• openclaw/openclaw#25592 — canonical cross-channel bug (Slack, Telegram, iMessage, WhatsApp, Feishu, Discord, WebChat). This PR closes the Slack-side leg via the dispatcher gate. Other channels using their own dispatchers (feishu, msteams) would need parallel fixes if they have equivalent gaps.
• openclaw/openclaw#46559 — closed unmerged; gateway subscriber layer, not dispatcher.
• openclaw/openclaw#51156 — closed unmerged; adds agents.defaults.enforceFinalTag (prompt-level, only helps tag-reasoning providers). Some form landed in current source.
• openclaw/openclaw#86175 — open, currently CONFLICTING. Modifies the same file with a different mechanism (buffer blocks until final; drop if NO_REPLY). Complementary, not overlapping: fix(auto-reply): turn-level NO_REPLY substrate-leak suppression (buffer-until-final) openclaw/openclaw#86175 handles "turn ended in NO_REPLY" case; this PR handles "channel opted out entirely" case. Neither obsoletes the other.

Related / follow-up (not in this PR)

• extensions/feishu/src/reply-dispatcher.ts and extensions/msteams/src/reply-dispatcher.ts are independent dispatcher implementations. Same class of gap likely applies; would want parallel patches, but out of scope here.
• openclaw plugins.allow is empty in the local config, which produces a repeated [plugins] plugins.allow is empty; discovered non-bundled plugins may auto-load warning in gateway logs. Unrelated to this fix.

Notes for reviewer

• Base is ReasonFoundation/openclaw:main (2 commits ahead of openclaw/openclaw:main with the Android fixes). Rebased cleanly.
• Happy to retarget upstream if you'd rather I opened the PR against openclaw/openclaw:main directly.
• Draft status because I want an internal review before this goes external, and because the runtime hasn't been restarted with the patched build yet (SHA-verified untouched — behavior verification is unit-test-only for now).