GitHub Repo
Open WebUI Community Proposes Truncation Status Fix After Responses Connections May Mark Incomplete Replies as Normal Endings
An October 31 report from the Open WebUI community says non-streaming replies over Responses API connections may lose their truncation signal, causing clients to treat incomplete answers as normally finished. The proposed fix has been updated but had not been merged as of the time of review.
On October 31, the Open WebUI community reported an API compatibility bug: when model output reaches the token limit, a non-streaming answer routed through a Responses API connection may still return finish_reason: "stop". The author said they reproduced the issue at the function level using v0.12.5 and a specified development revision; this was not an end-to-end test of a complete deployment. Issue report
The report concerns requests with stream: false and a model connection type set to Responses. The upstream result originally included status: "incomplete" and an output-limit reason, but the conversion function determined the finish reason only by checking for tool calls and did not read the incomplete status. The author used identical content with completed and incomplete statuses and got the same stop; after conversion through an Anthropic-compatible endpoint, it also became end_turn. Reproduction details
These fields directly affect application control flow. Anthropic’s official documentation defines end_turn as a natural completion and max_tokens as reaching the output limit, and recommends increasing the limit or continuing the response in the latter case. If a gateway erases this distinction, workflows that decide whether to continue based on the finish reason may stop too early. This is an engineering risk inferred from protocol semantics; there is no evidence of a large-scale deployment incident. Stop reason documentation
Related PR #33394 was updated on October 31 with a branch that reads the incomplete status: content filtering maps to content_filter, while other incomplete reasons map to length. The proposal also handles usage fields and stream format conversion. This means the non-streaming gap identified in the original report is covered by the current proposed fix, but the PR remains open and should not be treated as a fix in an official release. Fix proposal
Operators should track the merge and release, and test the endpoints they actually use with a low output limit to confirm that truncation triggers continuation or an alert. Validation should also cover content filtering and tool calls, so that checking only whether text displays correctly does not miss the effect of finish status on agent workflows.