openclaw - 💡(How to fix) Fix [Bug]: WhatsApp block streaming can suppress complete final replies after partial stream delivery

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

WhatsApp block streaming can suppress the complete final assistant reply after a partial streamed block was sent, leaving users with a visibly cut-off message and no expandable Read more.

Steps to reproduce

1. Run OpenClaw 2026.5.10-beta.6 with WhatsApp enabled and block streaming active for the WhatsApp reply path.
2. Trigger a WhatsApp auto-reply where the block reply pipeline streams a partial text block before the model run completes.
3. Let the model run complete with a longer final text payload that is not equal to any payload recorded by blockReplyPipeline.hasSentPayload(finalPayload).
4. Observe that the final complete text is suppressed because buildReplyPayloads() drops final payloads when blockReplyPipeline.didStream() is true and the pipeline is not aborted.

Expected behavior

The final complete reply should still be delivered unless the block reply pipeline can prove that the same final payload was already sent.

For channels like WhatsApp that do not edit a prior streamed message in place, a partial streamed block should not be treated as equivalent to the completed final assistant message.

Actual behavior

Two live WhatsApp replies were generated completely in OpenClaw, but the user-visible WhatsApp bubbles ended mid-answer with literal trailing ... and no expandable Read more.

Local code inspection showed the final-payload suppression gate was:

const shouldDropFinalPayloads =
  params.blockStreamingEnabled &&
  Boolean(params.blockReplyPipeline?.didStream()) &&
  !params.blockReplyPipeline?.isAborted();

That gate does not require hasSentPayload(finalPayload) to be true before dropping the final payload.

OpenClaw version

2026.5.10-beta.6 (af86c5bf6a658436d1f3453377784b92aa5e7cd2)

Operating system

Ubuntu 25.10

Install method

pnpm/dev checkout, running as a systemd user service from built dist/index.js

Model

openai/gpt-5.5

Provider / routing chain

OpenClaw gateway -> embedded Codex/OpenAI harness -> OpenAI model provider -> WhatsApp Web delivery

Additional provider/model setup details

The affected sessions used OpenClaw's embedded agent runtime with GPT-5.5. The transport was WhatsApp Web. The configured workaround was to set channels.whatsapp.blockStreaming=false.

Logs, screenshots, and evidence

Redacted local evidence:

Stored model output was complete for both affected runs:
- WhatsApp reply A: final assistant text length about 2170 chars; user-visible bubble ended at "support-capital mechanics..."
- WhatsApp reply B: final assistant text length about 1380 chars; user-visible bubble ended at "between May 7 and today..."

Relevant source path:
- src/auto-reply/reply/agent-runner-payloads.ts

Focused local regression coverage after patch:
- pnpm exec vitest run src/auto-reply/reply/agent-runner-payloads.test.ts extensions/whatsapp/src/auto-reply/monitor/inbound-dispatch.test.ts
- Result: 2 files passed, 71 tests passed

Live mitigation validation after patch:
- channels.whatsapp.blockStreaming=false
- /readyz returned ready:true, failing:[], eventLoop.degraded:false
- WhatsApp account status: running=true, connected=true, healthState=healthy

Related issue: #70921 covered the opposite duplicate-final failure mode. This report is the paired loss-of-final failure mode: the final is dropped too broadly after any successful stream.

Impact and severity

Affected: WhatsApp channel users with block streaming enabled.

Severity: High for affected chats because the assistant appears to answer but silently omits the end of the response.

Frequency: Intermittent in live use; observed in two separate WhatsApp group replies in the same morning.

Consequence: Users receive incomplete advice/reviews and cannot expand the message because the missing text was not delivered.

Additional information

Local mitigation disables block streaming for WhatsApp:

{
  "channels": {
    "whatsapp": {
      "blockStreaming": false
    }
  }
}

Local patch direction:

• Do not drop all final payloads just because didStream() is true.
• Skip a final payload only when blockReplyPipeline.hasSentPayload(payload) or directlySentBlockKeys proves the final payload was already delivered.
• Preserve the existing media-only follow-up behavior when text streamed but attached media has not been sent.