GitHub Repo
Open WebUI Community Reports Message Validation Regression in Development Build, Potentially Rejecting Automation and Prebuilt-Reply API Flows
An October 8 report from the Open WebUI community says a development build may reject generation requests when a reply message has already been created, preventing automations, sub-agents, and timers from writing answers. The same pattern appears in the documented server-side API flow, but the reporter says the latest stable release works; maintainers have yet to confirm or fix the issue.
On October 8, Open WebUI received a report of a regression in its development build: when chat history already contains an empty assistant reply message and a model is then asked to fill in the answer, the request may return HTTP 409 with the error Message already exists or has an invalid ID. The reporter listed the environment as Debian 13, installed via Git Clone, on dev commit 652d0cf. They also said the latest stable release and commits before the identified change still work. Community report
The trigger has clear implications for integrations. The report says that after changes related to shared chats, generation requests reject pre-created reply messages; automations, sub-agents, and timers all use this pattern. The simplest check is to create an automation and run it immediately, then see whether the new chat consistently remains unanswered. API users can create a chat containing a user message and an empty assistant message, then call /api/chat/completions with the same reply ID. These findings are still the reporter’s test results and have not been independently reproduced. Reproduction steps
Open WebUI’s public tool-calling documentation does require this pre-creation flow: first create a chat and an assistant message, then send chat_id, id, and stream: true so the server can execute multiple rounds of native tool calls, and finally read the answer from the chat history. If the report is confirmed, backend programs that integrate MCP, Workspace Tools, and built-in tools according to the documentation could be affected. Based on the documented architecture, compatibility between message validation and existing placeholder messages is the key boundary in this issue. Server-side tool-calling documentation
Engineering teams should watch whether a fix covers both the scheduling entry point and direct API calls, while continuing to accept valid placeholder messages and reject invalid IDs. Upgrade verification should also check that the final answer is written to the specified message, rather than only confirming that chat creation succeeded. At the time of review, the issue remained open and the page listed no related fix. The report mentions regression testing, but no test execution results were available, so it cannot yet be assumed that all development-build deployments are affected. Issue status