openclaw - 💡(How to fix) Fix Google Chat message-tool replies do not edit typing placeholder

Summary

Google Chat typing placeholders are not edited when the visible reply is delivered through message(action=send) for the current source conversation.

This leaves Google Chat group/space turns with two visible artifacts:

• the initial _BotName is typing..._ message
• the real reply sent by the message tool

The reply can be correctly threaded after the message-tool threading fix, but the provisional typing message still does not become the final reply.

Desired behavior

For Google Chat, a user-visible reply to the current inbound conversation should produce one visible threaded message:

1. OpenClaw posts the initial typing placeholder.
2. The agent produces the visible reply, whether through the normal automatic final-reply path or through current-source message(action=send) required by messages.groupChat.visibleReplies = "message_tool".
3. OpenClaw edits the typing placeholder into the first reply chunk, or otherwise consumes/cleans the placeholder without leaving a stale _BotName is typing..._ message.

The model should not need to know about Google Chat's placeholder implementation or call a special edit API.

Repro shape

Configuration shape:

{
  "channels": {
    "googlechat": {
      "enabled": true,
      "typingIndicator": "message",
      "replyToMode": "all"
    }
  },
  "messages": {
    "groupChat": {
      "visibleReplies": "message_tool"
    }
  }
}

Turn shape:

1. User mentions the agent in a Google Chat room/thread.
2. Google Chat monitor sends _BotName is typing..._ and stores typingMessageName.
3. Because group visible replies are tool-only, the prompt tells the agent normal final replies are private and visible output must use message(action=send).
4. The agent calls message(action=send) to the current source conversation.
5. The final assistant content is deduped/suppressed as already delivered through the message tool.

Actual

The message-tool reply is sent, but it bypasses deliverGoogleChatReply(...), so the typingMessageName owned by the Google Chat delivery path is not edited into the reply. The placeholder can remain visible as a separate stale typing message.

Expected

Current-source message(action=send) delivery for Google Chat should be integrated with the same provisional-message lifecycle as automatic delivery. At minimum it should clear the placeholder; ideally it should update the placeholder with the first text chunk so the UX matches the original Google Chat behavior.

Related work

• #1635 introduced Google Chat and the typing-message edit behavior for the normal delivery path.
• #71507 preserved reply text when typing-message update fails in the normal delivery path.
• #39843 / #39891 cover stale typing placeholders when no delivery happens after NO_REPLY.
• #80995 / #80996 cover message-tool replies escaping Google Chat threads; that fixes placement but not placeholder consumption/editing.

Scope boundary

This is not asking the agent to call a Google Chat edit API directly. The desired behavior is for OpenClaw's Google Chat current-source delivery plumbing to hide that channel detail from the model.