Since 0.12.0, every group save and every member add or remove 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 save finished. With a few thousand people online, saving a group took several seconds, and every one of those open chats reloaded its contents afterwards. When a group change can affect what someone may see, the server already makes that person's browser reconnect, and an open chat checks its access again on reconnect, so group changes now skip the recheck for everyone else. Folder and chat sharing changes keep it.
Postgres 16, 2,000-member group, one open chat per online user:
| Online users | Saving the group without permission changes, before | after | Adding a member, before | after |
| --- | --- | --- | --- | --- |
| 1,000 | 2.0 s | under 0.05 s | 2.2 s | under 0.05 s |
| 3,000 | 6.7 s | under 0.05 s | 6.6 s | under 0.05 s |
When an upstream provider rejects a request (e.g. a 400 for a
max_tokens value above the model's ceiling), the actionable error
message was only published to event sinks, which are invisible unless
an event function or webhook is configured. Admins had to query the
provider's API directly to diagnose failures (open-webui#27237).
Add a single log line in publish_model_provider_request_failed — the
chokepoint every upstream failure path (OpenAI-compatible chat,
embeddings, responses, token counting, and Ollama) already routes
through — recording status, provider, url, model, error code, and the
upstream message truncated to 1000 chars. 4xx logs at WARNING, 5xx at
ERROR. Client-facing responses are unchanged, so no additional error
detail is exposed in the chat.
Claude-Session: https://claude.ai/code/session_018VecyiPejru1EVF5yfe2sU
Co-authored-by: Claude <noreply@anthropic.com>
Classic298