Summary

The webchat channel sent NO_REPLY as visible text to WebSocket clients instead of suppressing it. Other channels (Telegram, Discord) already filter this token via the reply dispatcher, but the webchat streaming/outbound path bypassed this check.

Root Cause

In src/gateway/server-chat.ts, createAgentEventHandler() forwarded assistant stream text directly to webchat chat events without applying silent-token filtering:

• emitChatDelta(...) sent state: \"delta\" payloads from evt.data.text as-is.
• emitChatFinal(...) built final state: \"final\" message from chatRunState.buffers as-is.
• Call path: agent event handler branch for evt.stream === \"assistant\" (emitChatDelta) and lifecycle end/error (emitChatFinal).

Because this path bypasses the normal reply dispatcher normalization, NO_REPLY could leak both in streaming updates and in the final chat payload.

Changes

• Added silent-token filtering in webchat WS event path in src/gateway/server-chat.ts:
  • Imported isSilentReplyText and SILENT_REPLY_TOKEN from src/auto-reply/tokens.ts.
  • In emitChatDelta, suppress delta emission when streamed text is silent token.
  • In emitChatFinal, suppress final message when buffered text is silent token.
• Added focused tests in src/gateway/server-chat.agent-events.test.ts:
  • verifies NO_REPLY is filtered in streaming (no delta broadcast/node send)
  • verifies NO_REPLY is filtered in final (final event emitted with message: undefined)

Testing

• npm run lint ✅
• npm test -- src/gateway/server-chat.agent-events.test.ts ✅
• Attempted requested command npm test -- --testPathPattern=\"web\" ❌ (current Vitest CLI in this repo does not support --testPathPattern; returns Unknown option --testPathPattern)

Edge Cases Considered

• Partial streaming chunks containing NO_REPLY
• NO_REPLY with leading/trailing whitespace
• HEARTBEAT_OK (handled separately by heartbeat visibility suppression logic)
• Messages containing "NO_REPLY" as substring of legitimate text (not filtered by exact silent-token matcher)

🤖 AI-assisted (Robby + Cami) — verified bug in source, fix follows existing channel patterns

Greptile Overview

Greptile Summary

prevented NO_REPLY token from appearing in webchat stream deltas and final messages by adding isSilentReplyText checks in emitChatDelta and emitChatFinal

Key Changes

• imported isSilentReplyText and SILENT_REPLY_TOKEN from src/auto-reply/tokens.ts
• added silent token filter to streaming path (emitChatDelta) and final message path (emitChatFinal)
• added focused tests verifying NO_REPLY is suppressed in both streaming and final events

Issue Found

• emitChatDelta deletes the buffer on NO_REPLY, which breaks cumulative text tracking if more text streams after the silent token (see inline comment on src/gateway/server-chat.ts:232)

Confidence Score: 3/5

• safe to merge after fixing the buffer deletion issue
• the fix correctly addresses the NO_REPLY leak and follows existing channel patterns, but the buffer deletion in emitChatDelta will break text accumulation if streaming continues after the silent token
• src/gateway/server-chat.ts requires attention - the buffer deletion on line 233 needs to be removed

_{Last reviewed commit: 6adf2eb}