openclaw - 💡(How to fix) Fix Ensure transcript-to-client delivery consistency for channel-scoped sessions [1 pull requests]

Summary

Channel-scoped sessions currently have a durable transcript as the source of truth, but delivery to the originating client/channel can drift. In Discord, we sometimes see assistant final replies present in the session transcript / Control UI while the corresponding Discord message is missing.

Because Discord session keys explicitly include the client/channel target, for example agent:<agentId>:discord:channel:<channelId>[:thread:<threadId>], OpenClaw should be able to reconcile whether each transcripted assistant message has been delivered to its expected Discord surface.

Problem

When delivery fails or silently drops after a model response is written to the transcript:

• Control UI shows the assistant response
• the Discord thread/channel may not show it
• the user cannot tell whether this is generation failure or delivery failure
• there is no durable receipt linking transcript entry -> provider message id
• there is no safe automatic or operator-triggered reconciliation path

This creates session log / client-visible log inconsistency.

Expected behavior

For channel-scoped sessions, OpenClaw should track delivery state for assistant outputs that are expected to appear in the originating client/channel.

At minimum, operators should be able to tell:

• generated but not delivered
• delivery attempted and failed
• delivered successfully, with provider message id
• redelivered / reconciled

Proposed shape

Add a delivery receipt / reconciliation layer rather than treating this as cross-client fan-out.

Possible implementation:

• record delivery target metadata for final assistant transcript entries
• record provider message ids on successful sends
• mark delivery status in transcript metadata or a sidecar delivery ledger
• expose delivery state in Control UI/session preview
• add a best-effort reconciler for missing/failed client deliveries
• make re-delivery idempotent using transcript entry id -> provider message id mapping

This should not automatically mirror all client activity across surfaces. The guarantee should apply only to the expected origin delivery target for channel-scoped sessions.

Related behavior

This is adjacent to, but distinct from:

• multi-surface fan-out issues, where replies from WebChat/Control UI get delivered to another channel
• sessions_send internal replies not appearing in a bound Discord worker thread
• Control UI transcript rendering diverging from channel-visible logs

The core issue here is delivery-state drift between the durable transcript and the client-visible log.

Why this matters

For Discord-first operation, the Discord thread is the user-facing operational log, while Control UI is the canonical transcript viewer. If Discord delivery occasionally drops, the system needs a way to detect and repair that divergence rather than leaving users to manually compare Control UI and Discord.