openclaw - 💡(How to fix) Fix Wake-response telemetry: wake.response_sent event for operator-visible wake-cycle completion [1 comments, 2 participants]

Summary

OpenClaw already supports wake-injected active-session turns via the local wake socket, but operators do not currently get a durable event when the assistant response to that wake has actually completed.

Request: emit a wake.response_sent gateway event after a wake-injected user turn finishes streaming back from the live Claude session.

Proposed event

Event name: wake.response_sent

Payload:

{
  "schema": "openclaw.wake.response_sent.v1",
  "wake_id": "string",
  "sessionKey": "string",
  "sessionId": "string|null",
  "response_message_id": "string|null",
  "responded_at": "ISO-8601 timestamp",
  "source": "string"
}

Rationale

This closes the observability loop for wake-cycle delivery:

• wake.injected proves the user turn was injected.
• wake.response_sent proves the assistant completed a response to that wake.

Without the second event, operator UIs and cross-agent audit trails can show that a wake arrived but cannot reliably distinguish "response still in progress" from "response completed".

Implementation notes from local patch

The local Smith Crafts patch tracks wake IDs in a per-live-session in-flight map when injectTitusWakeIntoActiveSession succeeds, then drains that map in the live-session result completion path. Each drained wake ID emits one wake.response_sent event through the existing subscribeTitusWakeEvent / gateway broadcaster path.

The TUI renders a compact system line, for example:

[wake-response-sent: <wake_id_short> -> <source>]

Related issues

• Prior wake socket / active-session delivery: #83809
• Wake event bridge and TUI rendering: #84113
• Wake inbox drain durability: #84237