Bug type
Behavior bug (incorrect output/state without crash)
Summary
On Discord, early assistant commentary is often not committed immediately as a standalone visible message.
Instead, it appears to remain inside the in-progress draft / reply-dispatcher pipeline until a later stage, often surfacing only together with the final reply.
This reduces responsiveness.
More importantly, if the gateway restarts before that in-progress content is committed, the commentary may be lost entirely and never appear in Discord.
Steps to reproduce
A typical pattern is:
assistant emits a substantial early status message such as
“Good, I’ll enable Discord streaming, restart the gateway, and verify the result.”
then performs the config change / restart-sensitive action then later emits the final outcome
The early status message is long enough that this is not just a “minimum preview length” issue.
Even so, the message may remain buffered and fail to appear as an independent Discord message before the restart occurs.
As a result:
the user does not see the early acknowledgement immediately and if restart happens first, that commentary can be missing entirely from Discord
Expected behavior
If the assistant produces:
an immediate acknowledgement / commentary performs a tool call or long-running action later returns the final result
then the first commentary should be committed to Discord immediately as its own visible message, instead of remaining buffered until the final reply path.
If a restart happens after user-visible commentary has already been generated, that commentary should not be silently lost.
Actual behavior
Early commentary is often delayed and does not appear immediately in Discord.
It seems to stay in the in-progress draft / dispatcher pipeline.
In many cases it only appears together with the later final answer, making Discord feel less responsive.
If the gateway restarts before commit/flush, the commentary may never be delivered at all.
OpenClaw version
2026.3.23
Operating system
Ubuntu 24.04
Install method
No response
Model
openai-codex-gpt-5.4
Provider / routing chain
openclaw -> openai
Additional provider/model setup details
No response
Logs, screenshots, and evidence
Impact and severity
This causes two separate UX problems:
Reduced immediacy
Discord feels slower than the assistant actually is.
Message loss
restart-sensitive operations can silently drop already-generated user-visible commentary.
Additional information
This issue is not primarily about short preview thresholds.
Even long commentary messages can be delayed or lost because the core problem is the reply pipeline’s buffering/commit timing before Discord delivery is finalized.
This is based on local config/state checks plus code inspection.
Discord replies go through a draft/dispatcher pipeline:
createDiscordDraftStream(...)
createReplyDispatcherWithTyping(...)
sendFinalReply
sendBlockReply
sendToolResult
dispatcher.waitForIdle()
Draft preview thresholds exist (minInitialChars, throttleMs), but the issue described here is broader:
even sufficiently long early commentary can remain uncommitted the core problem is that early user-visible commentary is not durably committed to Discord immediately
This creates a loss window:
commentary already exists logically but Discord still has no committed message restart can happen during that window the user never sees that commentary
Bug type
Behavior bug (incorrect output/state without crash)
Summary
On Discord, early assistant commentary is often not committed immediately as a standalone visible message.
Instead, it appears to remain inside the in-progress draft / reply-dispatcher pipeline until a later stage, often surfacing only together with the final reply.
This reduces responsiveness.
More importantly, if the gateway restarts before that in-progress content is committed, the commentary may be lost entirely and never appear in Discord.
Steps to reproduce
A typical pattern is:
assistant emits a substantial early status message such as
“Good, I’ll enable Discord streaming, restart the gateway, and verify the result.”
then performs the config change / restart-sensitive action then later emits the final outcome
The early status message is long enough that this is not just a “minimum preview length” issue.
Even so, the message may remain buffered and fail to appear as an independent Discord message before the restart occurs.
As a result:
the user does not see the early acknowledgement immediately and if restart happens first, that commentary can be missing entirely from Discord
Expected behavior
If the assistant produces:
an immediate acknowledgement / commentary performs a tool call or long-running action later returns the final result
then the first commentary should be committed to Discord immediately as its own visible message, instead of remaining buffered until the final reply path.
If a restart happens after user-visible commentary has already been generated, that commentary should not be silently lost.
Actual behavior
Early commentary is often delayed and does not appear immediately in Discord.
It seems to stay in the in-progress draft / dispatcher pipeline.
In many cases it only appears together with the later final answer, making Discord feel less responsive.
If the gateway restarts before commit/flush, the commentary may never be delivered at all.
OpenClaw version
2026.3.23
Operating system
Ubuntu 24.04
Install method
No response
Model
openai-codex-gpt-5.4
Provider / routing chain
openclaw -> openai
Additional provider/model setup details
No response
Logs, screenshots, and evidence
Impact and severity
This causes two separate UX problems:
Reduced immediacy
Discord feels slower than the assistant actually is.
Message loss
restart-sensitive operations can silently drop already-generated user-visible commentary.
Additional information
This issue is not primarily about short preview thresholds.
Even long commentary messages can be delayed or lost because the core problem is the reply pipeline’s buffering/commit timing before Discord delivery is finalized.
This is based on local config/state checks plus code inspection.
Discord replies go through a draft/dispatcher pipeline:
createDiscordDraftStream(...)
createReplyDispatcherWithTyping(...)
sendFinalReply
sendBlockReply
sendToolResult
dispatcher.waitForIdle()
Draft preview thresholds exist (minInitialChars, throttleMs), but the issue described here is broader:
even sufficiently long early commentary can remain uncommitted the core problem is that early user-visible commentary is not durably committed to Discord immediately
This creates a loss window:
commentary already exists logically but Discord still has no committed message restart can happen during that window the user never sees that commentary