Two fixes:
1. onSettled orphan cleanup (Codex ID=2963834802): add cleanup in the streaming
dispatcher's onSettled callback for cases where the reply pipeline produces no
final payload — e.g. messaging-tool sends suppressed by agent-runner-payloads.ts,
or empty/heartbeat responses. Without this, onPartialReply could create a preview
post that is never finalized or deleted. The cleanup mirrors the existing logic in
#43041 (P5).
2. Initial-send retry storm (Codex ID=2963834806): call stopPatchInterval() in the
sendMessageMattermost catch block, mirroring the existing fix for patchMattermostPost
failures. Without this, a failed initial post attempt (missing post permission, DM
creation failure, etc.) causes the 200ms interval to retry indefinitely for the rest
of the response, flooding the API and gateway logs.
Two fixes:
1. Divergent-target flush (Codex ID=2962544342): when replyTargetDiverged is true
the flush is skipped to avoid creating a preview in the wrong thread, but the
patch interval was not stopped and any in-flight first sendMessageMattermost
was not awaited. If that send resolved after the divergent delivery returned,
it created a stray preview post with no cleanup path. Fix: always stop the
interval and wait for patchSending to settle (up to 2s) even on the divergent
path, so streamMessageId is populated if the send resolves during this window
and the orphan cleanup below can capture and delete it.
2. Patch-failure retry storm (Codex ID=2962544347): after a patchMattermostPost
failure in the schedulePatch interval, streamMessageId remained set and every
subsequent 200ms tick retried the same failing request, spamming the API until
final delivery. Fix: call stopPatchInterval() in the catch block so retries
stop immediately. The preview stays frozen at its last successful text; deliver()
will patch or replace it when the final reply arrives.
When the final payload has no text (media-only), the in-place text patch branch
is skipped, but the streamed preview post was previously left in the channel
alongside the attachment. The orphanedStreamId capture now always holds the
stream post ID (not only on divergent-target paths), and a new branch delivers
the media payload first and deletes the stale preview only after delivery
succeeds. If delivery fails, the preview stays visible as a fallback.
Three fixes from latest Codex review:
1. Compute replyTargetDiverged before flushPendingPatch: previously the flush
always ran first, potentially creating a preview post under effectiveReplyToId
even when the final payload would land in a different thread. Now flush is
skipped when the target diverges, avoiding a transient post in the wrong thread.
2. Divergent-thread cleanup order: when replyTargetDiverged, deliver the correct
message first and delete the orphaned preview only afterward. This matches the
same pattern as the fallback path — if delivery fails, the user keeps the
partial preview rather than losing all visible output.
3. disableBlockStreaming: changed fallback from false to undefined so accounts
without an explicit blockStreaming setting preserve the agent blockStreamingDefault
instead of having block streaming forced on.
Two fixes from latest Codex review:
1. Truncation dedup: compare lastSentText against the truncated text (not the full
rawText) in both schedulePatch and flushPendingPatch. Previously, once a reply
grew past textLimit the guard compared the growing rawText against the stored
rawText, so the post would be patched every 200 ms with the same truncated body
— running into avoidable Mattermost rate limiting on long responses.
2. Orphan cleanup order: in the final-edit fallback path, deliver the replacement
message first and only delete the orphaned stream post afterward. If the fallback
send also fails, the user keeps the partial preview instead of losing all visible
output.
Three fixes addressing Codex review feedback:
1. Streaming opt-in: change streamingEnabled from (blockStreaming !== false) to
(blockStreaming === true) so accounts without an explicit blockStreaming setting
preserve their agent blockStreamingDefault instead of having edit-in-place
streaming silently enabled.
2. Text limit: apply textLimit truncation in schedulePatch and flushPendingPatch
before sending/patching. Intermediate preview posts only need the first chunk;
final delivery goes through deliverMattermostReplyPayload which applies full
chunking. This prevents oversize patch loops when responses exceed the limit.
3. Reply target divergence: when the final payload carries an explicit replyToId
that resolves to a different root than the streaming post was created under
(e.g. a [[reply_to_current]] directive), skip the in-place patch and fall
through to normal delivery so the reply lands in the correct thread. Any
orphaned stream post is deleted before the correct reply is sent.
Race condition: lastSentText was set synchronously before the async send/patch
completed, so a failed request was treated as delivered and subsequent ticks
skipped retrying. flushPendingPatch also didn't wait for in-flight interval ticks,
causing it to exit early (text === lastSentText guard) when a tick had just fired
but hadn't resolved yet, leaving streamMessageId null and forcing final delivery
to send a new post instead of patching the streamed one.
Fixes:
- schedulePatch interval: set lastSentText only after successful send/patch
- flushPendingPatch: wait up to 2s for in-flight patchSending before proceeding
- flushPendingPatch: set lastSentText after network success, not before
Both functions called the global fetch directly, bypassing the fetchImpl
stored in the client closure. This silently ignored any custom fetch
implementation passed to createMattermostClient (test mocks, proxy-aware
fetchers, SSRF guards).
Switch both to client.request<void>() which uses fetchImpl, auto-injects
the Authorization header, handles Content-Type for JSON bodies, and
propagates errors consistently with every other client function.
uploadMattermostFile retains its direct fetch call (multipart/form-data
conflicts with request's automatic Content-Type injection).
Addresses Greptile review: 'New functions bypass client.request,
ignoring custom fetchImpl'.
When account.blockStreaming is unset, pass undefined instead of false for
disableBlockStreaming so downstream get-reply-directives inherits the
agent-level default rather than forcing block streaming on.
Affected paths: button-click interactions (handleInteractiveMenuInteraction)
and model picker confirmations (handleModelPickerInteraction).
slash-http.ts already used undefined correctly; this brings monitor.ts
into alignment.
Addresses Codex P2 review: 'Preserve inherited block-streaming default
for model picker replies' and 'Preserve default block-streaming behavior
for button replies'.
Rebased onto v3.12 main. Upstream extracted deliver logic to reply-delivery.ts,
so streaming now wraps deliverMattermostReplyPayload() instead of replacing
the inline deliver body.
Changes:
- client.ts: add patchMattermostPost() + deleteMattermostPost() API helpers
- monitor.ts: inject streaming state (schedulePatch, flushPendingPatch, setInterval)
before main inbound createReplyDispatcherWithTyping only (3 dispatch paths exist,
only main handler gets streaming via unique humanDelay+typingCallbacks anchor)
- monitor.ts: upgrade deliver signature to (payload, info) for isFinal detection
- monitor.ts: wrap deliverMattermostReplyPayload() with isFinal streaming logic
(final+streaming: patch in-place or fallback; non-streaming: delegate to helper)
- monitor.ts: add onPartialReply + disableBlockStreaming override in replyOptions
pnpm check: no new errors introduced (pre-existing errors on main unrelated to this PR)
Fixes: https://github.com/openclaw/openclaw/issues/XXXX
PR: https://github.com/openclaw/openclaw/pull/33506
