Bug report

[Alex-Van26]

Hermes Web UI Group Chat Bug Report

Summary

Group chat (beta) agents process messages (reach "final" phase) but responses are not delivered back to the chat UI.

Environment

• Hermes Web UI version: 0.6.15 (also tested on 0.6.17)
• Hermes Agent: latest (git install)
• Platform: macOS (ARM64)
• Node.js: v24.16.0
• Browser: (user tested on standard browsers)
• LLM Provider: DeepSeek (deepseek-v4-flash)

Steps to Reproduce

1. Create a group chat room (e.g., "油管项目组")
2. Add 2+ agents (e.g., yt-prod, yt-analytics, yt-content, yt-ops)
3. Send a message in the room
4. Observe that agents process the message (visible in server.log) but responses are never delivered to the chat UI

Expected Behavior

Agents' responses should appear in the group chat room after processing.

Actual Behavior

• Agents successfully join the room: [AgentClients] 视频制作 joined room: mqiccohkv4fmsq
• Agents process context and reach "final" phase: "phase":"final","source":"cache","msg":"[GroupChat] full context estimate"
• But the final response is never delivered to the chat UI
• No error messages are logged after "phase: final"
• After some time (hours), agents get "Not in room" errors: [AgentClients] 视频制作: error handling message: Not in room
• Bridge worker sockets exist but responses don't flow through

Log Evidence

Normal flow (agents connected):

[AgentClients] 视频制作 joined room: mqiccohkv4fmsq
[GroupChat] full context estimate  → phase: build → decision: skip
[GroupChat] full context estimate  → phase: final
→ *** NO RESPONSE DELIVERED *** ←

After degradation (hours later):

[AgentClients] 视频制作: error handling message: Not in room
[AgentClients] 视频制作: failed to send error message: Not in room

Key Observations

1. The IPC bridge workers (hermes_bridge.py --worker-profile <name>) connect successfully
2. Context estimates show proper processing (build → final phases)
3. The final LLM response is generated but never routed back through the WebSocket to the browser
4. After prolonged operation, all agents disconnect from rooms simultaneously
5. Room data is stored in memory (not persisted to SQLite) → restart loses room state
6. The room's triggerTokens (100000) is never exceeded despite context growth

Suggested Fix Areas

1. Response delivery pipeline after "phase: final" — trace why the response is generated but not sent
2. WebSocket message routing from bridge worker back to browser client
3. Agent reconnection logic — should retry more aggressively
4. Room state persistence — currently memory-only, should write to SQLite for crash recovery

How to Reproduce Easily

# Create a room with 2+ agents, send a message, watch server.log
tail -f ~/.hermes-web-ui/logs/server.log | grep -E "joined room|final|error|Not in room"

Contact

Submitter: 老范 (Alex) — Hermes Agent user from China

[x2yazi]

@Alex-Van26

这个 Issue 主要是写给跟我一样还在学习阶段的同学的。

当我们刚开始接触 GitHub 的时候，很自然会把 Star 数当作判断一个项目好坏的重要指标。Star 多 = 项目好，这个逻辑看起来很合理，对吧？

但这个项目让我学到了一课：Star 数是可以买的。

看看数据：过去 120 小时内新增了约 2357 颗星。follower 数全是 0，following 也是 0，仓库数为 0。

这意味着，你以为的"几千人认可的好项目"，实际可能只有几十个真实用户。

那新手应该怎么判断一个项目的质量呢？

1. 看 Issue 区——有没有真实用户在提问和反馈
2. 看提交记录——项目是不是在持续更新
3. 看文档——README 写得清不清楚，有没有示例
4. 看 PR——有没有外部贡献者参与
5. 搜一搜——在技术论坛上有没有真实的使用评价

不要只看数字，要看背后的真实内容。这个教训我也是今天才学到的，希望能帮到你们。

真金不怕火炼，假星经不起推敲。
违规已明，举报已发，违规流量清理与项目访问终止，已在推进。