PR #73721: fix(ui): deliver live chat events on runId match when sessionKey differs (#73716)

• Repository: openclaw/openclaw
• Author: hclsys
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/73721

Description (problem / solution / changelog)

What

Fixes #73716. Control UI's handleChatEvent previously dropped any payload whose sessionKey did not match state.sessionKey exactly:

if (payload.sessionKey !== state.sessionKey) {
  return null;
}

When the UI was holding a raw alias (e.g. main) but the gateway emitted live chat events under the canonical session key (e.g. agent:main:main), live deltas and finals for the in-flight client run were silently dropped. The user saw no live response and had to refresh the page to see the persisted reply.

Fix

Accept events when EITHER the sessionKey matches OR the active client run's runId matches the payload's runId:

const sessionMatches = payload.sessionKey === state.sessionKey;
const activeRunMatches =
  state.chatRunId != null &&
  typeof payload.runId === "string" &&
  payload.runId === state.chatRunId;
if (!sessionMatches && !activeRunMatches) {
  return null;
}

The runId check is gated on the UI having an active run (state.chatRunId != null), so sub-agent / fleet announces with a different runId still cannot leak into an unrelated session — the existing payload.runId !== state.chatRunId guard a few lines below continues to handle that case.

Test changes

• Renamed returns null when sessionKey does not match → returns null when sessionKey does not match and no active run is in flight to clarify the precondition (the existing assertion still holds — no active run).
• New accepts events whose runId matches the active client run even when sessionKey differs (#73716) pins the regression: raw main UI state, gateway emits agent:main:main, runId match → delta delivered.
• New still drops events when neither sessionKey nor runId matches belt-and-braces case pinning that the existing sub-agent/fleet announce protection is preserved.

Pre-implement audit

1. Existing-helper check (vincentkoc #57341). No helper introduced — the active-run match uses existing state fields (state.chatRunId, payload.runId). ✅
2. Shared-helper caller check (steipete #60623). handleChatEvent is module-scoped and called only from the chat-event subscription. The behavior change is widening the accept condition (logical OR), so callers that already match by sessionKey keep behaving identically. ✅
3. Broader-fix rival scan (steipete #68270). Zero rival PRs reference #73716. ✅

Verified locally

npx oxlint ui/src/ui/controllers/chat.ts ui/src/ui/controllers/chat.test.ts
# Found 0 warnings and 0 errors.

npx vitest run ui/src/ui/controllers/chat.test.ts
# Tests  52 passed (52)

lobster-biscuit: 73716-control-ui-runid-fallback

Sign-Off:

• I have read and agree to the OpenClaw Contributor License Agreement.

Changed files

• CHANGELOG.md (modified, +4/-0)
• ui/src/ui/controllers/chat.test.ts (modified, +63/-1)
• ui/src/ui/controllers/chat.ts (modified, +12/-1)

PR #73534: fix(telegram): scope native quote streaming guard to real quotes (#73505)

• Repository: openclaw/openclaw
• Author: hclsys
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/73534

Description (problem / solution / changelog)

What

Fixes #73505. When channels.telegram.replyToMode is set to anything other than "off", partial-stream preview is silently disabled for plain replies even though editMessageText round-trips with reply_to_message_id unchanged. The result is that operators with replyToMode: "first" see no streaming preview at all — text appears only after the run completes.

Root cause

bot-message-dispatch.ts builds a replyQuoteByMessageId map for native-quote candidate lookups during delivery, then computes:

const hasNativeQuoteReply =
  replyToMode !== "off" && Object.keys(replyQuoteByMessageId).length > 0;

Under replyToMode !== "off" the dispatcher unconditionally calls addTelegramNativeQuoteCandidate(replyQuoteByMessageId, ctxPayload.MessageSid ?? msg.message_id, ...) for the inbound message itself, so any inbound message with text populates the map and trips hasNativeQuoteReply → canStreamAnswerDraft = false → no preview lane.

The reason streaming is incompatible with native quote replies is the Telegram quote parameter, which editMessageText cannot re-send. Plain reply_to_message_id (no quote) does not have that constraint — and the dispatcher already passes draftReplyToMessageId into createTelegramDraftStream, which means the rest of the codepath is built to handle this case.

Fix

Tighten the guard to require an actual user-selected quote, matching the same replyQuoteText && replyQuoteMessageId != null pattern already used a few lines above to gate addTelegramNativeQuoteCandidate for explicit reply targets:

const hasNativeQuoteReply =
  replyToMode !== "off" && replyQuoteText != null && replyQuoteMessageId != null;

replyQuoteText is only set when ctxPayload.ReplyToIsQuote is true, and replyQuoteMessageId is only set when that quote points at a non-external resolvable message. Together they describe the only case where streaming truly cannot work.

Behavior preserved

• Quote-bearing replies (ReplyToIsQuote=true with text + resolvable id) still take the non-streaming path — covered by the existing skips answer draft preview for same-chat selected quotes test.
• replyQuoteByMessageId is still passed verbatim to deliverReplies for fallback handling — covered by the existing passes native quote candidates for current message replies and passes native quote candidates for explicit reply targets tests, which still assert the same map payload.

Test changes

• passes native quote candidates for current message replies — flipped from asserting createTelegramDraftStream is NOT called to asserting it IS called. The map-payload assertion is unchanged: candidates are still attached for the eventual final delivery.
• New regression test keeps answer draft preview for plain replies in groups with replyToMode set — pins #73505 behavior directly with replyToMode: "first" + streamMode: "partial" + plain inbound message → expects createTelegramDraftStream and draftStream.update("Hello").

Verified locally

npx oxlint extensions/telegram/src/bot-message-dispatch.ts extensions/telegram/src/bot-message-dispatch.test.ts
# Found 0 warnings and 0 errors.

npx vitest run extensions/telegram/src/bot-message-dispatch.test.ts
# Tests  109 passed (109)

npx vitest run extensions/telegram/src/bot/delivery.test.ts
# Tests  41 passed (41)

lobster-biscuit: 73505-replytomode-streaming-guard

Sign-Off:

• I have read and agree to the OpenClaw Contributor License Agreement.

Changed files

• CHANGELOG.md (modified, +1/-0)
• extensions/telegram/src/bot-message-dispatch.test.ts (modified, +45/-1)
• extensions/telegram/src/bot-message-dispatch.ts (modified, +9/-1)