Bug type
Behavior bug (incorrect output/state without crash)
Summary
On Discord, the assistant's main reply/result is sometimes not reflected in chat immediately even when the underlying work seems to be already done.
Recent user-facing examples were simple lookup-style requests such as:
- KRW/USD exchange-rate lookup
- Bitcoin price lookup
In these cases, the visible Discord message arrives late enough to create timing confusion (for example: it feels like the result is ready internally but the chat surface still has not updated, or a later request/context makes the delayed reply feel out of sync).
Steps to reproduce
A representative pattern:
- In a Discord chat backed by OpenClaw, ask a short lookup question that normally completes quickly
- e.g. "원/달러 환율 알려줘"
- e.g. "비트코인 가격 알려줘"
- Optionally send another nearby request while waiting
- Observe that the assistant's visible Discord reply may land later than expected, or late enough to create timing/order confusion in the conversation
Expected behavior
Once the assistant's main result is ready, it should be committed to Discord immediately (or with minimal bounded delivery latency).
Back-to-back short requests should still preserve clear, real-time ordering and not make the user wonder whether the system is stalled.
Actual behavior
The Discord-visible reply can arrive noticeably later than the user expects for lightweight requests.
This creates a mismatch between:
- internal completion / perceived readiness of the result
- actual user-visible commit of the message in Discord
The result is a chat UX that feels less real-time than the underlying execution and can cause timing confusion.
OpenClaw version
2026.3.23-2
Operating system
macOS 15.x / Darwin 24.6.0
Install method
Global npm install
Model
openai-codex/gpt-5.4
Provider / routing chain
openclaw -> openai
Additional provider/model setup details
No response
Logs, screenshots, and evidence
No logs attached yet.
This report is based on live user-facing Discord behavior. The recent concrete examples were short market lookup requests (KRW/USD exchange rate, Bitcoin price) where the chat reflection/delivery felt late enough to be noticeable.
Impact and severity
High UX / trust impact.
Even simple informational requests can feel broken if the main result is not reflected in Discord immediately after completion.
The user expectation here is effectively:
main result ready -> immediately visible in chat
Additional information
This may be related to, but is not obviously identical to:
Please investigate the handoff from reply generation / main completion to Discord outbound commit, especially for:
- quick tool-driven lookup turns
- short same-turn replies
- back-to-back Discord requests where delivery timing confusion becomes obvious
If this is the same root cause as an existing Discord reply buffering / dispatch / listener-blocking issue, linking or consolidating would still be helpful — but from the user side the key problem is: the result should show up in Discord immediately when it is ready.
Bug type
Behavior bug (incorrect output/state without crash)
Summary
On Discord, the assistant's main reply/result is sometimes not reflected in chat immediately even when the underlying work seems to be already done.
Recent user-facing examples were simple lookup-style requests such as:
In these cases, the visible Discord message arrives late enough to create timing confusion (for example: it feels like the result is ready internally but the chat surface still has not updated, or a later request/context makes the delayed reply feel out of sync).
Steps to reproduce
A representative pattern:
Expected behavior
Once the assistant's main result is ready, it should be committed to Discord immediately (or with minimal bounded delivery latency).
Back-to-back short requests should still preserve clear, real-time ordering and not make the user wonder whether the system is stalled.
Actual behavior
The Discord-visible reply can arrive noticeably later than the user expects for lightweight requests.
This creates a mismatch between:
The result is a chat UX that feels less real-time than the underlying execution and can cause timing confusion.
OpenClaw version
2026.3.23-2
Operating system
macOS 15.x / Darwin 24.6.0
Install method
Global npm install
Model
openai-codex/gpt-5.4
Provider / routing chain
openclaw -> openai
Additional provider/model setup details
No response
Logs, screenshots, and evidence
No logs attached yet.
This report is based on live user-facing Discord behavior. The recent concrete examples were short market lookup requests (KRW/USD exchange rate, Bitcoin price) where the chat reflection/delivery felt late enough to be noticeable.
Impact and severity
High UX / trust impact.
Even simple informational requests can feel broken if the main result is not reflected in Discord immediately after completion.
The user expectation here is effectively:
main result ready -> immediately visible in chat
Additional information
This may be related to, but is not obviously identical to:
Please investigate the handoff from reply generation / main completion to Discord outbound commit, especially for:
If this is the same root cause as an existing Discord reply buffering / dispatch / listener-blocking issue, linking or consolidating would still be helpful — but from the user side the key problem is: the result should show up in Discord immediately when it is ready.