openclaw - 💡(How to fix) Fix [Bug]: Discord partial/block streaming can emit misleading mid-output fragments [1 comments, 2 participants]

Summary

Discord partial/block streaming can expose awkward or misleading mid-output fragments in-channel during long turns, especially around tool-progress / progress-like output. This is separate from the final-send sanitizer bug fixed in #78559.

Observed while debugging

During a live Discord debugging session with streaming.mode=off and normal Discord replies enabled:

• final tool-progress messages were being handled by the normal reply delivery path;
• the final-send sanitizer issue made 📖 Read: / 🛠️ Exec: disappear, while ✍️ Write: stayed visible;
• separately, partial/block streaming behavior still produced confusing intermediate channel messages/fragments during longer turns.

The sanitizer bug has a concrete fix in #78559. This issue tracks the remaining streaming UX/runtime behavior so it does not get conflated with the sanitizer fix.

Why separate from #78559

#78559 addresses the final Discord send boundary:

• mark legitimate tool-progress payloads;
• preserve those marked progress labels in the front-channel safety scrubber;
• keep stripping actual internal trace/scaffolding lines.

This issue is about the earlier live/partial/block streaming path and when/how Discord sends intermediate output while a turn is still running.

Expected behavior

When Discord streaming is disabled or configured to avoid partial output, Discord should not emit misleading mid-output fragments. If progress/status is emitted, it should be explicitly classified and rendered consistently, not accidentally treated as assistant prose or sanitizer leakage.

Notes

Related existing issue found during triage:

• #32868 — block replies not delivered before tool execution (same-channel)

This may share code paths with createReplyDispatcherWithTyping, block replies, and Discord draft/live preview handling, but I have not root-caused it enough to propose a patch yet.