Patching preview text then delivering media separately splits a captioned-file
reply into two posts: a text-only preview + captionless file attachment.
New logic in the isFinal branch:
- Text-only payload: patch in place as before (no change for common case)
- Media payload: skip the patch, reset state, deliver full payload via
deliverMattermostReplyPayload (text+media together), then delete preview.
- Patch failure: same fallback as media payload — full delivery + delete.
After a successful patchMattermostPost in the isFinal branch, the code returned
immediately without delivering any media attachments. deliverMattermostReplyPayload
is the only path that uploads/sends media, so caption+image/file/audio payloads
were silently dropping the attachment whenever streaming was active and the patch
succeeded.
Fix: after a successful patch, check whether the payload has mediaUrls/mediaUrl.
If so, call deliverMattermostReplyPayload with text=undefined to deliver only the
media through the normal attachment path.
Add patchInflight Promise tracking to P4 (feat/mattermost-block-streaming-rebased),
mirroring the existing P5 approach. The onSettled cleanup previously used a 3-second
busy-wait on patchSending, which would race on slow Mattermost links: if the first
preview POST takes longer than 3s the cleanup exits early, patchSending is forced false,
and when the POST later resolves it creates an orphan post that is never deleted.
Fix: track the interval tick's async function as patchInflight. onSettled awaits it
directly so the cleanup always captures the final streamMessageId, regardless of how
long the POST takes. (Codex ID=2964616785)
Two fixes:
1. Failure latch (Codex ID=2964357928): add previewSendFailed boolean that is set true
in both the initial-send and patch-edit catch blocks (alongside stopPatchInterval).
schedulePatch() checks it before re-arming the interval, so subsequent onPartialReply
calls during a run with a permanent failure (missing permission, DM-creation error)
no longer recreate the timer and retry indefinitely.
2. patchInterval in onSettled guard (Codex ID=2964357925): onSettled now triggers
cleanup when patchInterval is non-null, even if streamMessageId and patchSending
are still falsy. This covers the window between schedulePatch arming the interval
and the first 200ms tick flipping patchSending — if the run ends in that window
(same-target messaging-tool sends, empty/heartbeat replies), the interval is now
stopped and the pending state is cleared.
When the first preview POST is still in flight (patchSending=true, streamMessageId=null),
the previous onSettled check was skipped entirely — the POST would resolve after cleanup
and leave an orphaned preview post with no interval to clear it.
Fix: trigger cleanup when either streamMessageId is set OR patchSending is true.
Stop the interval immediately, clear pending state, then wait up to 3s for patchSending
to clear before capturing the final streamMessageId and deleting the post.
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
Add GLIBC_TUNABLES, MAVEN_OPTS, SBT_OPTS, GRADLE_OPTS, ANT_OPTS,
DOTNET_ADDITIONAL_DEPS to blockedKeys and GRADLE_USER_HOME to
blockedOverrideKeys in the host exec security policy.
Closes#22681
Channel tests were always using process forks, missing the shared
transform cache that vmForks provides. This caused ~138s import
overhead per file. Now uses vmForks when available, matching the
pattern already used by unit-fast and extensions suites.
Delete all experiment plans, proposals, research docs, and the
kilo-gateway-integration design doc. These are internal planning
docs that do not belong on the public docs site.
- 12 English experiment files
- 5 zh-CN experiment translations
- 1 design doc (kilo-gateway-integration)
- Remove nav groups from docs.json (English + zh-CN)
- Remove 3 redirects pointing to deleted experiment pages
- Remove dead experiment links from hubs.md
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Delete all 7 refactor design docs and the zh-CN translations.
Remove the zh-CN nav group from docs.json.
These were orphaned from English nav and accessible only by
direct URL. Internal design docs do not belong on the public
docs site.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
