Gateway: hide NO_REPLY-only entries from chat.history by liuxiaopai-ai · Pull Request #32082 · openclaw/openclaw

liuxiaopai-ai · 2026-03-02T19:22:26Z

Summary

filter chat.history responses to drop assistant transcript entries that are exactly the silent token (NO_REPLY)
keep substantive assistant replies unchanged (only exact silent-token-only messages are removed)
add regression coverage for chat.history to ensure NO_REPLY entries do not appear in returned history

Fixes #32015.

Security Impact

None.

Repro + Verification

Repro (before)

Create a session where transcript includes assistant entry with text/content exactly NO_REPLY.
Call chat.history.
Returned messages include NO_REPLY, which can render as visible bubble in Webchat.

Verification (after)

pnpm exec vitest run src/gateway/server.chat.gateway-server-chat.test.ts
pnpm lint src/gateway/server-methods/chat.ts src/gateway/server.chat.gateway-server-chat.test.ts CHANGELOG.md
pnpm tsgo

Human Verification

confirmed chat.history excludes assistant NO_REPLY-only messages
confirmed normal user and assistant messages remain in order

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 8b9d06a68c

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

chatgpt-codex-connector · 2026-03-02T19:26:32Z

src/gateway/server-methods/chat.ts

+      if (typed.type !== "text" || typeof typed.text !== "string") {
+        return undefined;


Handle output_text blocks in silent history filtering

isSilentAssistantHistoryMessage only treats content blocks with type === "text" as candidates, so assistant entries like content: [{ type: "output_text", text: "NO_REPLY" }] are not filtered and still leak into chat.history. This matters because the gateway/OpenAI paths already use output_text blocks, and downstream history rendering reads .text without requiring type: "text", so users can still see visible NO_REPLY bubbles in those sessions.

Useful? React with 👍 / 👎.

greptile-apps · 2026-03-02T19:26:59Z

Greptile Summary

This PR filters out assistant messages whose content is exactly the internal NO_REPLY silent token from chat.history responses, preventing them from rendering as visible bubbles in the Webchat UI. The implementation adds two helper functions (isSilentAssistantHistoryMessage and dropSilentAssistantHistoryMessages) that slot cleanly into the existing message-processing pipeline, and a regression test confirms the happy path.

Key findings:

Logic bug in isSilentAssistantHistoryMessage (src/gateway/server-methods/chat.ts, lines 211–216): when entry.text is a non-silent string (e.g., "Hello"), the first if block evaluates to false and execution falls through to the entry.content check. If entry.content is "NO_REPLY", the function incorrectly returns true and the message is dropped despite having real content in text. The guard should short-circuit on entry.text alone (see inline comment for suggested fix).
The test suite covers the array-of-blocks content format but does not exercise the text-field-plus-content="NO_REPLY" edge case exposed by the above bug.
CHANGELOG entry and pipeline ordering look correct.

Confidence Score: 3/5

Safe to merge for the primary scenario, but carries a logic bug that could silently drop messages with a real text field and a content of "NO_REPLY".
The feature itself is straightforward and the test covers the common case. However, the fall-through from the entry.text guard to the entry.content check is a genuine logic error: a message with substantive content in text but content = "NO_REPLY" would be incorrectly filtered out. This warrants a fix before merging to avoid subtle data-loss bugs in edge-case history entries.
src/gateway/server-methods/chat.ts — specifically isSilentAssistantHistoryMessage lines 211–216.

_{Last reviewed commit: 8b9d06a}

greptile-apps

_{3 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

greptile-apps · 2026-03-02T19:27:03Z

src/gateway/server-methods/chat.ts

+  if (typeof entry.text === "string" && isSilentReplyText(entry.text, SILENT_REPLY_TOKEN)) {
+    return true;
+  }
+  if (typeof entry.content === "string") {
+    return isSilentReplyText(entry.content, SILENT_REPLY_TOKEN);
+  }


Non-silent text field falls through to content check

When entry.text is a non-empty string that is not the silent token (e.g., "Hello"), the first if block evaluates to false and execution falls through to the entry.content check. If entry.content happens to be the string "NO_REPLY", the function returns true and the message is incorrectly dropped — even though the message carries real text in its text field.

The guard on entry.text should be a complete short-circuit: if a text field is present, its value alone should determine whether the message is silent, and the content field should not be consulted at all.

Suggested change

if (typeof entry.text === "string" && isSilentReplyText(entry.text, SILENT_REPLY_TOKEN)) {

return true;

}

if (typeof entry.content === "string") {

return isSilentReplyText(entry.content, SILENT_REPLY_TOKEN);

}

if (typeof entry.text === "string") {

return isSilentReplyText(entry.text, SILENT_REPLY_TOKEN);

}

if (typeof entry.content === "string") {

return isSilentReplyText(entry.content, SILENT_REPLY_TOKEN);

}

Prompt To Fix With AI

This is a comment left during a code review. Path: src/gateway/server-methods/chat.ts Line: 211-216 Comment: **Non-silent `text` field falls through to `content` check** When `entry.text` is a non-empty string that is *not* the silent token (e.g., `"Hello"`), the first `if` block evaluates to `false` and execution falls through to the `entry.content` check. If `entry.content` happens to be the string `"NO_REPLY"`, the function returns `true` and the message is incorrectly dropped — even though the message carries real text in its `text` field. The guard on `entry.text` should be a complete short-circuit: if a `text` field is present, its value alone should determine whether the message is silent, and the `content` field should not be consulted at all. ```suggestion if (typeof entry.text === "string") { return isSilentReplyText(entry.text, SILENT_REPLY_TOKEN); } if (typeof entry.content === "string") { return isSilentReplyText(entry.content, SILENT_REPLY_TOKEN); } ``` How can I resolve this? If you propose a fix, please make it concise.

liuxiaopai-ai · 2026-03-02T19:30:40Z

Addressed, thanks for the catch.

I pushed a follow-up commit (d14048b) that fixes the precedence bug in isSilentAssistantHistoryMessage:

if entry.text is present, we now decide solely from entry.text (short-circuit) instead of falling through to entry.content
this prevents dropping messages that have real text but content: "NO_REPLY"

Also added a regression case in server.chat.gateway-server-chat.test.ts:

assistant message with text: "real text field reply" and content: "NO_REPLY" remains visible in chat.history

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: d14048b7ce

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

chatgpt-codex-connector · 2026-03-02T19:36:14Z

src/gateway/server-methods/chat.ts

+        return undefined;
+      }
+      const typed = block as { type?: unknown; text?: unknown };
+      if (typed.type !== "text" || typeof typed.text !== "string") {


Treat output_text blocks as silent in chat.history

isSilentAssistantHistoryMessage only keeps blocks with type === "text", so assistant entries like content: [{ type: "output_text", text: "NO_REPLY" }] are not filtered and still appear in chat.history. This is a regression for gateway/OpenAI-style transcripts because we already treat output_text as normal textual content elsewhere (see src/gateway/session-utils.fs.ts:379), so users can still get visible NO_REPLY bubbles in sessions that use those block types.

Useful? React with 👍 / 👎.

Takhoffman · 2026-03-02T22:39:44Z

Closing as superseded by #32183, which is now merged and covers the NO_REPLY history/UI guardrails with regression tests.

Gateway: hide NO_REPLY-only chat history entries

8b9d06a

openclaw-barnacle bot added app: web-ui App: web-ui gateway Gateway runtime size: S experienced-contributor labels Mar 2, 2026

chatgpt-codex-connector bot reviewed Mar 2, 2026

View reviewed changes

Telegram: skip deleteMyCommands before setMyCommands

9915ce7

greptile-apps bot reviewed Mar 2, 2026

View reviewed changes

Gateway: fix NO_REPLY history filter precedence

d14048b

openclaw-barnacle bot added the channel: telegram Channel integration: telegram label Mar 2, 2026

chatgpt-codex-connector bot reviewed Mar 2, 2026

View reviewed changes

ademczuk mentioned this pull request Mar 2, 2026

fix(webchat): suppress NO_REPLY token in chat transcript rendering #32183

Merged

5 tasks

Takhoffman closed this Mar 2, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Gateway: hide NO_REPLY-only entries from chat.history#32082

Gateway: hide NO_REPLY-only entries from chat.history#32082
liuxiaopai-ai wants to merge 3 commits intoopenclaw:mainfrom
liuxiaopai-ai:codex/webchat-hide-no-reply-history-32015

liuxiaopai-ai commented Mar 2, 2026

Uh oh!

chatgpt-codex-connector bot left a comment

Uh oh!

chatgpt-codex-connector bot Mar 2, 2026

Uh oh!

greptile-apps bot commented Mar 2, 2026

Uh oh!

greptile-apps bot left a comment

Uh oh!

greptile-apps bot Mar 2, 2026

Uh oh!

liuxiaopai-ai commented Mar 2, 2026

Uh oh!

chatgpt-codex-connector bot left a comment

Uh oh!

chatgpt-codex-connector bot Mar 2, 2026

Uh oh!

Takhoffman commented Mar 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

		if (typed.type !== "text" \|\| typeof typed.text !== "string") {
		return undefined;

Uh oh!

Conversation

liuxiaopai-ai commented Mar 2, 2026

Summary

Security Impact

Repro + Verification

Repro (before)

Verification (after)

Human Verification

Uh oh!

chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector bot Mar 2, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot commented Mar 2, 2026

Greptile Summary

Confidence Score: 3/5

Uh oh!

greptile-apps bot left a comment

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Mar 2, 2026

Choose a reason for hiding this comment

Uh oh!

liuxiaopai-ai commented Mar 2, 2026

Uh oh!

chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector bot Mar 2, 2026

Choose a reason for hiding this comment

Uh oh!

Takhoffman commented Mar 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants