When a model calls search_notes with a multi-word query containing spaces and/or hyphens (e.g., "to-do list reminders"), it should return notes whose title or content contains all of those terms somewhere in the text—regardless of where each term appears.
Actual Behavior
search_notes returns [] for every multi-word query. Only single-word or single hyphenated-term queries produce results.
Steps to Reproduce
Install Open WebUI v0.8.12 via Docker with PostgreSQL backend.
Create a Note with a hyphenated term in the title (e.g., My To-Do List) and body content containing additional words like reminders, schedule, etc.
Create a custom model with Builtin Tools > Notes enabled, using Native function calling.
Start a chat and ask something that would trigger a search_notes call with multiple terms (e.g., "What does my to-do list say about reminders?").
Observe the search_notes tool call returns [] despite the note containing all search terms.
A single-term query like to-do works correctly and returns the note.
Root cause: In backend/open_webui/models/notes.py, search_notes() normalizes the query by stripping all hyphens and spaces from the entire string before performing a single ILIKE match:
normalized_query=query_key.replace('-','').replace(' ','')# "to-do list reminders" -> "todolistreminders" -- never matches as a contiguous substring
The hyphen-stripping logic was intended to let todo match to-do (single-term normalization), but applying it to the whole multi-word query concatenates all terms into one string that never appears contiguously in any note content.
Fix: Split the query into individual terms, normalize each independently (strip hyphens), and require all terms to match somewhere in the title or content (AND semantics). Single-term behavior is unchanged.
Additionally, snippet extraction in tools/builtin.py attempts to find the entire multi-word query as one contiguous substring to center the preview—which also never matches for multi-word input. Fixed to locate the first matching individual term instead.
Logs & Screenshots
Tool call trace from chat history (PostgreSQL):
name="search_notes" arguments='{"query": "multi word query with hyphens"}' result="[]"
name="search_notes" arguments='{"query": "another multi term search"}' result="[]"
After fix, validated directly against PostgreSQL and inside the container:
Multi-word query with 4 terms: 1 result (was 0)
Two-term query: 2 results (was 0)
Single-term query: 3 results (unchanged -- no regression)
Additional Information
This also affects the scenario in #23362 -- when notes are attached to a folder and the model uses native function calling, notes are not auto-injected into context. The LLM falls back to search_notes, which hits this SQL bug and returns empty.
Installation Method: Docker Open WebUI Version: v0.8.12 Operating System: Windows 11 / WSL2 + Docker Desktop Browser: Chrome 136
Originally created by @jlgill on GitHub (Apr 10, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/23565
### Expected Behavior
When a model calls `search_notes` with a multi-word query containing spaces and/or hyphens (e.g., `"to-do list reminders"`), it should return notes whose title or content contains all of those terms somewhere in the text—regardless of where each term appears.
### Actual Behavior
`search_notes` returns `[]` for **every** multi-word query. Only single-word or single hyphenated-term queries produce results.
### Steps to Reproduce
1. Install Open WebUI v0.8.12 via Docker with PostgreSQL backend.
2. Create a Note with a hyphenated term in the title (e.g., `My To-Do List`) and body content containing additional words like `reminders`, `schedule`, etc.
3. Create a custom model with Builtin Tools > Notes enabled, using Native function calling.
4. Start a chat and ask something that would trigger a `search_notes` call with multiple terms (e.g., "What does my to-do list say about reminders?").
5. Observe the `search_notes` tool call returns `[]` despite the note containing all search terms.
6. A single-term query like `to-do` works correctly and returns the note.
**Root cause:** In `backend/open_webui/models/notes.py`, `search_notes()` normalizes the query by stripping **all** hyphens and spaces from the entire string before performing a single `ILIKE` match:
```python
normalized_query = query_key.replace('-', '').replace(' ', '')
# "to-do list reminders" -> "todolistreminders" -- never matches as a contiguous substring
```
The hyphen-stripping logic was intended to let `todo` match `to-do` (single-term normalization), but applying it to the whole multi-word query concatenates all terms into one string that never appears contiguously in any note content.
**Fix:** Split the query into individual terms, normalize each independently (strip hyphens), and require all terms to match somewhere in the title or content (AND semantics). Single-term behavior is unchanged.
Additionally, snippet extraction in `tools/builtin.py` attempts to find the entire multi-word query as one contiguous substring to center the preview—which also never matches for multi-word input. Fixed to locate the first matching individual term instead.
### Logs & Screenshots
Tool call trace from chat history (PostgreSQL):
```
name="search_notes" arguments='{"query": "multi word query with hyphens"}' result="[]"
name="search_notes" arguments='{"query": "another multi term search"}' result="[]"
```
After fix, validated directly against PostgreSQL and inside the container:
```
Multi-word query with 4 terms: 1 result (was 0)
Two-term query: 2 results (was 0)
Single-term query: 3 results (unchanged -- no regression)
```
### Additional Information
- This also affects the scenario in #23362 -- when notes are attached to a folder and the model uses native function calling, notes are not auto-injected into context. The LLM falls back to `search_notes`, which hits this SQL bug and returns empty.
- Fix branch: [jlgill/gillson-open-webui:fix/search-notes-per-term-matching](https://github.com/jlgill/gillson-open-webui/tree/fix/search-notes-per-term-matching) (rebased on `dev`)
- Files changed: `backend/open_webui/models/notes.py`, `backend/open_webui/tools/builtin.py`
**Installation Method:** Docker
**Open WebUI Version:** v0.8.12
**Operating System:** Windows 11 / WSL2 + Docker Desktop
**Browser:** Chrome 136
Stop spamming our discussions and issues, you commented this, and opened 2 issues and 5 discussions with the same exact text in 3 minutes or so. STOP. Final warning.
<!-- gh-comment-id:4222151672 -->
@Classic298 commented on GitHub (Apr 10, 2026):
Stop spamming our discussions and issues, you commented this, and opened 2 issues and 5 discussions with the same exact text in 3 minutes or so. STOP. Final warning.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @jlgill on GitHub (Apr 10, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/23565
Expected Behavior
When a model calls
search_noteswith a multi-word query containing spaces and/or hyphens (e.g.,"to-do list reminders"), it should return notes whose title or content contains all of those terms somewhere in the text—regardless of where each term appears.Actual Behavior
search_notesreturns[]for every multi-word query. Only single-word or single hyphenated-term queries produce results.Steps to Reproduce
My To-Do List) and body content containing additional words likereminders,schedule, etc.search_notescall with multiple terms (e.g., "What does my to-do list say about reminders?").search_notestool call returns[]despite the note containing all search terms.to-doworks correctly and returns the note.Root cause: In
backend/open_webui/models/notes.py,search_notes()normalizes the query by stripping all hyphens and spaces from the entire string before performing a singleILIKEmatch:The hyphen-stripping logic was intended to let
todomatchto-do(single-term normalization), but applying it to the whole multi-word query concatenates all terms into one string that never appears contiguously in any note content.Fix: Split the query into individual terms, normalize each independently (strip hyphens), and require all terms to match somewhere in the title or content (AND semantics). Single-term behavior is unchanged.
Additionally, snippet extraction in
tools/builtin.pyattempts to find the entire multi-word query as one contiguous substring to center the preview—which also never matches for multi-word input. Fixed to locate the first matching individual term instead.Logs & Screenshots
Tool call trace from chat history (PostgreSQL):
After fix, validated directly against PostgreSQL and inside the container:
Additional Information
search_notes, which hits this SQL bug and returns empty.dev)backend/open_webui/models/notes.py,backend/open_webui/tools/builtin.pyInstallation Method: Docker
Open WebUI Version: v0.8.12
Operating System: Windows 11 / WSL2 + Docker Desktop
Browser: Chrome 136
@Classic298 commented on GitHub (Apr 10, 2026):
Stop spamming our discussions and issues, you commented this, and opened 2 issues and 5 discussions with the same exact text in 3 minutes or so. STOP. Final warning.