[PR #1456] [MERGED] docs: check that a system message contains a filter's text, not that one equals it #1418

New issue

Closed

opened 2026-10-18 21:31:19 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-18 21:31:19 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/open-webui/docs/pull/1456
Author: @silentoplayz
Created: 10/7/2026
Status: ✅ Merged
Merged: 10/7/2026
Merged by: @silentoplayz

Base: main ← Head: docs/filter-request-system-message-check

📝 Commits (1)

942ada6 docs: check that a system message contains a filter's text, not that one equals it

📊 Changes

1 file changed (+6 additions, -1 deletions)

View changed files

📝 docs/features/extensibility/plugin/functions/filter.mdx (+6 -1)

📄 Description

Summary

The Filter Function page's example of a request filter that is safe to run more than once still adds its line again on every hop of a tool loop when the chat has another system message, such as a system prompt from the chat controls.

Before each call to the model, Open WebUI merges all system messages into one. On the next hop, the example's "Be concise." is part of that longer merged message, so its check that a message's content equals the text never matches, and the filter inserts it again. Anyone who copies the example gets the duplication it was written to prevent.

This changes the example to check whether a system message contains the text, and adds a short paragraph explaining why an equality check is not enough.

None.

Checklist

I have reviewed the relevant documentation and matched the existing style.
This PR meets Open WebUI's contribution standards: it is accurate, relevant to users, narrowly scoped, maintainable, and not promotional content, advertising, lead generation, SEO placement, or a request to list a product, service, provider, integration, gateway, tool, or company primarily for visibility.
I understand that PRs that do not meet these standards may be closed without review and will not be merged. Repeated, low-quality, off-topic, promotional, or intentionally misleading submissions may result in the contributor being blocked from future participation in Open WebUI repositories.

Notes for reviewers

I first saw the duplication on a test instance while building a filter that adds a system message with this kind of check.

The merge is merge_system_messages, called through normalize_messages_for_model after the request filters run, both for the first call and for every hop of the tool loop, and each hop starts from the already merged messages. It is the same on v0.11.4 and on dev.

I ran both versions of the example through four hops, using Open WebUI's own merge_system_messages between hops and adding a tool result each time:

Example	Chat has a system prompt	Copies of the line after 4 hops
Current	No	1
Current	Yes	4
This PR	No	1
This PR	Yes	1

npm run build passes.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/open-webui/docs/pull/1456 **Author:** [@silentoplayz](https://github.com/silentoplayz) **Created:** 10/7/2026 **Status:** ✅ Merged **Merged:** 10/7/2026 **Merged by:** [@silentoplayz](https://github.com/silentoplayz) **Base:** `main` ← **Head:** `docs/filter-request-system-message-check` --- ### 📝 Commits (1) - [`942ada6`](https://github.com/open-webui/docs/commit/942ada6a5cf489e895b82b26135b3c0e6c419bfe) docs: check that a system message contains a filter's text, not that one equals it ### 📊 Changes **1 file changed** (+6 additions, -1 deletions) <details> <summary>View changed files</summary> 📝 `docs/features/extensibility/plugin/functions/filter.mdx` (+6 -1) </details> ### 📄 Description ## Summary The Filter Function page's example of a `request` filter that is safe to run more than once still adds its line again on every hop of a tool loop when the chat has another system message, such as a system prompt from the chat controls. Before each call to the model, Open WebUI merges all system messages into one. On the next hop, the example's `"Be concise."` is part of that longer merged message, so its check that a message's content equals the text never matches, and the filter inserts it again. Anyone who copies the example gets the duplication it was written to prevent. This changes the example to check whether a system message contains the text, and adds a short paragraph explaining why an equality check is not enough. ## Related issue or discussion None. ## Checklist - [x] I have reviewed the relevant documentation and matched the existing style. - [x] This PR meets Open WebUI's contribution standards: it is accurate, relevant to users, narrowly scoped, maintainable, and not promotional content, advertising, lead generation, SEO placement, or a request to list a product, service, provider, integration, gateway, tool, or company primarily for visibility. - [x] I understand that PRs that do not meet these standards may be closed without review and will not be merged. Repeated, low-quality, off-topic, promotional, or intentionally misleading submissions may result in the contributor being blocked from future participation in Open WebUI repositories. ## Notes for reviewers I first saw the duplication on a test instance while building a filter that adds a system message with this kind of check. The merge is `merge_system_messages`, called through `normalize_messages_for_model` after the `request` filters run, both for the first call and for every hop of the tool loop, and each hop starts from the already merged messages. It is the same on v0.11.4 and on `dev`. I ran both versions of the example through four hops, using Open WebUI's own `merge_system_messages` between hops and adding a tool result each time: | Example | Chat has a system prompt | Copies of the line after 4 hops | | :--- | :--- | :--- | | Current | No | 1 | | Current | Yes | 4 | | This PR | No | 1 | | This PR | Yes | 1 | `npm run build` passes. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-18 21:31:19 +00:00