Skip to content

fix: forward clarify events from bridge to Web Chat UI#1023

Open
Macgrady4Ever wants to merge 2 commits into
EKKOLearnAI:mainfrom
Macgrady4Ever:fix/clarify-bridge-event-forwarding
Open

fix: forward clarify events from bridge to Web Chat UI#1023
Macgrady4Ever wants to merge 2 commits into
EKKOLearnAI:mainfrom
Macgrady4Ever:fix/clarify-bridge-event-forwarding

Conversation

@Macgrady4Ever
Copy link
Copy Markdown

Summary

Web Chat UI fails to render clarify() popups because the bridge agent does not forward clarify.requested and clarify.resolved events to the Web Chat frontend.

Bug

When the AI agent calls clarify() with a question and choices, the event is received by the bridge but silently dropped — the Web Chat frontend never gets notified. The user sees no popup, and the conversation stalls until the 5-minute clarify timeout expires.

Root Cause

handle-bridge-run.ts only forwards approval.requested / approval.resolved events. Clarify events have the same bridge→UI forwarding requirement but were missing.

Fix

Added two event branches in applyBridgeChunkAsync(), mirroring the approval pattern:

  • clarify.requested — forwards question, choices, clarify_id, timeout_ms to the UI
  • clarify.resolved — forwards clarify_id resolution to the UI

Both use pushState() + emit(), consistent with the existing approval handler.

Changed Files

  • packages/server/src/services/hermes/run-chat/handle-bridge-run.ts (+19 lines)

Test Plan

  1. Start Web Chat with a profile that uses bridge mode
  2. Trigger a scenario where the agent calls clarify()
  3. Verify the clarify popup renders with question text and clickable choices
  4. Select a choice and verify the conversation continues

The clarify() tool calls were correctly emitted by the Python bridge
as 'clarify.requested' events, and the frontend had full support for
rendering the clarify bar and handling user responses. However, the
middle layer in handle-bridge-run.ts (applyBridgeChunkAsync) was
missing the event-handling branches for clarify.requested and
clarify.resolved, causing them to be silently dropped in the for loop.

This caused the Web Chat clarify bar to never render, resulting in a
5-minute timeout and a broken interaction flow.

Fix: add 'clarify.requested' and 'clarify.resolved' branches following
the same pattern as the existing 'approval.requested'/'approval.resolved'
handlers — constructing payloads and emitting them via Socket.IO so the
frontend store receives them and ChatPanel.vue renders the clarify bar.
…for clarify events

- Use replaceState instead of pushState (consistent with approval pattern)
- Add Array.isArray guard on choices (defensive, from main)
@Macgrady4Ever
Copy link
Copy Markdown
Author

@EKKOLearnAI 您好, 这个确实很影响体验, 会卡很久webchat界面.请作者大大看一眼.

@EKKOLearnAI
Copy link
Copy Markdown
Owner

我最新合并的mian分支还有这种情况吗?

@Macgrady4Ever
Copy link
Copy Markdown
Author

我最新合并的mian分支还有这种情况吗?

嗯, 我刚才回到家, 用家里电脑用v0.6.1的代码刚升级的, 发现一旦clarify还是有这个卡住的问题

@EKKOLearnAI
Copy link
Copy Markdown
Owner

可以试下最新的main分支 空白/plan就会触发

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants