Adding, updating or removing knowledge base files through the API sent back the metadata of every file in the knowledge base, and so did renaming a knowledge base or changing its access. These calls got slower as the knowledge base grew, so bulk ingestion through the API lost speed with every batch. Adding or updating files now returns only those files, while removing a file, renaming or changing access returns an empty files list. API clients that read the files list from these responses now get only the affected files; the full list stays available, paginated, from `GET /api/v1/knowledge/{id}/files`. Timings with a local mock embedding server that answers instantly, median of 5 runs (at 1,000 files the per-file work of a batch still hides the difference):
| Files already in the knowledge base | Call | Before | After | Response size before | Response size after |
|---|---|---|---|---|---|
| 1,000 | batch add of 100 files | 519 ms | 528 ms | 437 KB | 39 KB |
| 10,000 | batch add of 100 files | 679 ms | 476 ms | 4.0 MB | 39 KB |
| 10,000 | single file add | 184 ms | 36 ms | 4.0 MB | 0.6 KB |
Closes#31397
When the owner of a shared folder moved a chat a member created to another folder inside the shared folder, the chat lost the member's pin and dropped out of their Pinned list. The owner's move now keeps the member's pin, just as it already keeps the chat's unread status for them. Moving your own chat into a folder still unpins it, as before, so it shows up in that folder.
Fixes#33341
Every kb_exec command (ls, cat, grep and the rest) and the knowledge base sync check listed the knowledge base by loading each file's full extracted text, even though only names, folders, sizes and hashes were used. On large knowledge bases every call took seconds, held hundreds of MB of memory and blocked the server for other users while it ran. The listing now reads only those fields, and file text is still loaded per file when a command needs it, as before. Output is byte-identical.
5,005 files (5,000 of 50 KB in 50 folders plus 5 of 10 MB, 292 MB of text), median of 3 calls, Postgres 17:
| kb_exec command | before | after | peak memory before | after |
|---|---|---|---|---|
| `ls` | 2.34 s | 0.20 s | 874 MB | 243 MB |
| `ls folder_000/` | 2.15 s | 0.20 s | 873 MB | 243 MB |
| `cat folder_000/doc_000_001.md` | 1.07 s | 0.17 s | 855 MB | 243 MB |
| `grep -n needle folder_000/` | 1.24 s | 0.31 s | 871 MB | 243 MB |
| `grep -c needle large_0.md` | 1.19 s | 0.22 s | 874 MB | 306 MB |
On SQLite the same calls drop from 0.50-1.03 s to 0.16-0.29 s.
Fixes#33322
Mistral OCR always sent the mistral-ocr-latest model with no other request options, so admins could not stay on an older OCR model or send the model name a Mistral-compatible endpoint such as Azure AI Foundry expects. A new Parameters field under Admin Panel > Settings > Documents, shown when Mistral OCR is the extraction engine and also available as the MISTRAL_OCR_PARAMS environment variable, takes a JSON object that is merged into every OCR request: {"model": "mistral-ocr-2512"} replaces the default model, and any other field is sent to the OCR endpoint as given. It works the same with and without the Use Base64 switch, and when it is left empty the request is unchanged.
Closes#19707
Filing an old chat into a folder made it look recently active: it jumped to the top of the sidebar under Today, and a batch of old chats sorted into folders ended up ordered by when each was moved. Moving a chat into or out of a folder now keeps its last activity date, so it is sorted and grouped by when it was really last active. Moving your own chat still clears its unread dot as before, and when the owner of a shared folder reorganizes your chat within it, the chat no longer turns unread for you.
Closes#30362
* perf: renaming a folder or deleting all chats takes seconds when many users are online
Renaming, sharing, moving or deleting a folder, and deleting all chats, each made the server recheck access for every chat that any online user had open in a browser tab, one database lookup at a time, before the request finished, and every one of those open chats reloaded its contents afterwards. Any user can do these, so with a few thousand people online every such click took several seconds and reloaded everyone's open chat. Owners keep access to their own chats (a role change or account deletion already disconnects them), so the recheck now skips owners entirely, with no lookup and no reload, and only checks people viewing someone else's chat and chats that no longer exist. Anyone who lost access is still removed from the chat as before.
Postgres 16, one open chat per online user, 2% of them viewing someone else's chat, time for a folder rename (the other actions above run the same recheck):
| Online users | No Redis, before | No Redis, after | Redis, before | Redis, after |
| --- | --- | --- | --- | --- |
| 1,000 | 2.2 s | 0.12 s | 2.5 s | 0.23 s |
| 3,000 | 6.9 s | 0.60 s | 7.7 s | 0.78 s |
* refac: collect the open chats with a plain loop
Same behaviour, the owner lookup now reads more plainly.
* refac: shorten the owner comment in the chat access sweep
When a group change affects its members (new permissions, parent group or default models, or deleting the group), the server makes every member's browser reconnect so it picks up the new permissions without a page reload. To find each member's connections it read through the whole list of connected users again for every single member, so saving a 2,000-member group with 3,000 people online spent almost 9 seconds on this with Redis as the websocket manager, and about 1 second without. It now finds all members' connections in one pass.
Changing one permission on a 2,000-member group, time the save spends making members reconnect:
| Online users | Redis, before | Redis, after | No Redis, before | No Redis, after |
| --- | --- | --- | --- | --- |
| 1,000 | 2.8 s | 0.15 s | 0.09 s | <0.01 s |
| 3,000 | 8.7 s | 0.28 s | 1.2 s | <0.01 s |
When the model asked the user a question, or a tool call was approved or rejected, the reply was saved in a way that broke adding anything to it later in the same turn. If the model then generated an image, the image was created but never shown, the tool returned "unsupported operand type(s) for +: 'NoneType' and 'list'" and the model kept retrying, generating more hidden images. Progress status updates for that reply were also silently dropped. Both now work after a question or tool approval.
Fixes#32678
Chat search checks the whole query and each word in it separately. With a single word those are the same check, so every chat got searched twice. It is now searched once, with the same results. On PostgreSQL with 2164 chats (533 MB of chat data) a one-word search is about 40% faster:
| search | before | after |
|---|---|---|
| proxy | 6.0 s | 3.6 s |
| opnsense | 6.1 s | 3.8 s |
| no match | 5.4 s | 3.0 s |
Refs #32266
Timothy Jaeryang Baek
Classic298andGitHub
G30andGitHub