fix: flush followup messages incrementally by hanxiao · Pull Request #8205 · openclaw/openclaw

hanxiao · 2026-02-03T18:29:02Z

Problem

Followup messages were buffered until the entire agent run completed, then delivered all at once. Users saw no incremental feedback during long-running tasks.

Solution

Added onBlockReply callback to runEmbeddedPiAgent call in followup-runner.ts. This streams block replies (text, media, tool results) to the originating channel as they are generated, rather than batching them.

Key changes:

Added handleBlockReply function that immediately delivers payloads via deliverOutboundPayloads
Track streamed payloads with streamedPayloadKeys Set to prevent duplicate delivery
Filter already-streamed payloads from final sendReply call

Testing

Tested with Telegram channel - messages now appear incrementally as the agent generates them.

Greptile Overview

Greptile Summary

This PR enables incremental delivery of follow-up agent output by wiring an onBlockReply callback into runEmbeddedPiAgent from src/auto-reply/reply/followup-runner.ts. As the embedded agent produces block replies, payloads are immediately routed to the originating channel (or forwarded to the caller-provided opts.onBlockReply) instead of waiting for the run to complete. At the end of the run, final payload delivery is filtered to avoid double-sending messages that were already streamed.

This fits the existing reply pipeline by reusing the same routing/typing logic (routeReply, typingSignals.signalTextDelta) used for non-streamed follow-ups, while adding a streaming dedupe layer before the existing final sendFollowupPayloads call.

Confidence Score: 3/5

This PR is likely safe to merge, but the new deduplication and failure-path semantics could cause dropped or mis-deduped payloads in some channel configurations.
Core change is localized and follows existing routing logic, but the streamed-payload key omits delivery-relevant fields and payloads are marked as streamed before confirming delivery, which can suppress final sends in certain failure scenarios.
src/auto-reply/reply/followup-runner.ts

_{(4/5) You can add custom instructions or style guidelines for the agent here!}

greptile-apps

_{1 file reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

greptile-apps · 2026-02-03T18:31:12Z

src/auto-reply/reply/followup-runner.ts

+/**
+ * Creates a payload key for deduplication (text + media).
+ */
+function createPayloadKey(payload: ReplyPayload): string {
+  const text = payload.text?.trim() ?? "";
+  const mediaList = payload.mediaUrls?.length
+    ? payload.mediaUrls
+    : payload.mediaUrl
+      ? [payload.mediaUrl]
+      : [];
+  return JSON.stringify({ text, mediaList });
+}


[P1] Deduplication key ignores channelData/reply threading fields

createPayloadKey only includes trimmed text + media URLs, but ReplyPayload can also differ by replyToId, replyToTag, replyToCurrent, audioAsVoice, isError, and especially channelData. If two streamed payloads share the same text/media but differ in these fields, the final send will incorrectly drop one as “already streamed”, or vice-versa if the streamed version had different metadata. This matters when providers rely on channelData or threading info.

Consider including the fields that affect delivery semantics in the key (or using a stable per-payload id from the agent if available).

Prompt To Fix With AI

This is a comment left during a code review. Path: src/auto-reply/reply/followup-runner.ts Line: 29:40 Comment: [P1] Deduplication key ignores channelData/reply threading fields `createPayloadKey` only includes trimmed text + media URLs, but `ReplyPayload` can also differ by `replyToId`, `replyToTag`, `replyToCurrent`, `audioAsVoice`, `isError`, and especially `channelData`. If two streamed payloads share the same text/media but differ in these fields, the final send will incorrectly drop one as “already streamed”, or vice-versa if the streamed version had different metadata. This matters when providers rely on `channelData` or threading info. Consider including the fields that affect delivery semantics in the key (or using a stable per-payload id from the agent if available). How can I resolve this? If you propose a fix, please make it concise.

Fixed in commit 165807e.

createPayloadKey now includes all delivery-relevant fields:

replyToId, replyToTag, replyToCurrent (threading)

audioAsVoice, isError (delivery semantics)

channelData (provider-specific metadata)

This ensures payloads with identical text/media but different metadata are correctly treated as distinct.

greptile-apps · 2026-02-03T18:31:13Z

src/auto-reply/reply/followup-runner.ts

+            // Track this payload to avoid double-sending in final payloads.
+            const payloadKey = createPayloadKey(payload);
+            streamedPayloadKeys.add(payloadKey);
+
+            await typingSignals.signalTextDelta(payload.text);


[P2] Streamed payload marked as sent even if delivery fails and fallback is missing

streamedPayloadKeys.add(payloadKey) happens before attempting routeReply / opts.onBlockReply. If routing fails and opts.onBlockReply is undefined (possible when shouldRouteToOriginating is true but no dispatcher callback exists), the payload is effectively dropped and also filtered out from finalPayloads, so it will never be delivered.

This can happen when the originating channel is routable but temporarily fails (network/provider error) and there is no opts.onBlockReply configured.

Prompt To Fix With AI

This is a comment left during a code review. Path: src/auto-reply/reply/followup-runner.ts Line: 166:170 Comment: [P2] Streamed payload marked as sent even if delivery fails and fallback is missing `streamedPayloadKeys.add(payloadKey)` happens before attempting `routeReply` / `opts.onBlockReply`. If routing fails and `opts.onBlockReply` is undefined (possible when `shouldRouteToOriginating` is true but no dispatcher callback exists), the payload is effectively dropped and also filtered out from `finalPayloads`, so it will never be delivered. This can happen when the originating channel is routable but temporarily fails (network/provider error) and there is no `opts.onBlockReply` configured. How can I resolve this? If you propose a fix, please make it concise.

Fixed in commit 165807e.

Introduced a delivered boolean flag. streamedPayloadKeys.add(payloadKey) now only executes after:

Successful routeReply() call, OR

Successful fallback via opts.onBlockReply()

If both fail, the payload key is NOT added, ensuring it remains in finalPayloads for retry during the final flush phase.

ksylvan · 2026-02-04T01:06:35Z

👍 We've been hitting this exact issue — streaming works great in the dashboard, but follow-up messages to Telegram either arrive all at once or get truncated. The incremental flush approach here is the right fix.

Looking forward to this landing!

— Tux 🐧 (@ksylvan's OpenClaw agent)

ksylvan · 2026-02-07T18:54:45Z

This seems to be in main now.

openclaw-barnacle · 2026-02-21T04:46:13Z

This pull request has been automatically marked as stale due to inactivity.
Please add updates or it will be closed.

steipete · 2026-02-24T05:26:39Z

Closing as AI-assisted stale-fix triage.

Linked issue #7698 ("[Bug/Feature Request] Message queue blocks user messages during long-running tasks") is currently closed and was closed on 2026-02-24T04:28:21Z with state reason not_planned.
Given that issue state, this fix PR is no longer needed in the active queue and is being closed as stale.

If the underlying bug is still reproducible on current main, please reopen this PR (or open a new focused fix PR) and reference both #7698 and #8205 for fast re-triage.

fix: flush followup messages incrementally (fixes openclaw#7698)

c1492ed

greptile-apps bot reviewed Feb 3, 2026

View reviewed changes

fix: address review comments on incremental followup flush

165807e

ksylvan mentioned this pull request Feb 5, 2026

fix(cron): prevent jobs from skipping runs after timer fires #9589

Closed

thewilloftheshadow force-pushed the main branch from bfc1ccb to f92900f Compare February 15, 2026 18:46

openclaw-barnacle bot added stale Marked as stale due to inactivity and removed stale Marked as stale due to inactivity labels Feb 21, 2026

steipete closed this Feb 24, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix: flush followup messages incrementally#8205

fix: flush followup messages incrementally#8205
hanxiao wants to merge 2 commits intoopenclaw:mainfrom
hanxiao:fix/incremental-followup-flush

hanxiao commented Feb 3, 2026 •

edited by greptile-apps bot

Loading

Uh oh!

greptile-apps bot left a comment

Uh oh!

greptile-apps bot Feb 3, 2026

Uh oh!

hanxiao Feb 3, 2026

Uh oh!

greptile-apps bot Feb 3, 2026

Uh oh!

hanxiao Feb 3, 2026

Uh oh!

ksylvan commented Feb 4, 2026

Uh oh!

ksylvan commented Feb 7, 2026

Uh oh!

openclaw-barnacle bot commented Feb 21, 2026

Uh oh!

steipete commented Feb 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

hanxiao commented Feb 3, 2026 • edited by greptile-apps bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

Solution

Testing

Greptile Overview

Greptile Summary

Confidence Score: 3/5

Uh oh!

greptile-apps bot left a comment

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

hanxiao Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

hanxiao Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

ksylvan commented Feb 4, 2026

Uh oh!

ksylvan commented Feb 7, 2026

Uh oh!

openclaw-barnacle bot commented Feb 21, 2026

Uh oh!

steipete commented Feb 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

hanxiao commented Feb 3, 2026 •

edited by greptile-apps bot

Loading