[PR #22496] [CLOSED] [codex] Fix Responses API tool follow-ups and continuation payloads #97764

New Issue

GiteaMirror · 2026-05-16T00:24:32-05:00

GiteaMirror commented

2026-05-16 00:24:32 -05:00

📋 Pull Request Information

Original PR: https://github.com/open-webui/open-webui/pull/22496
Author: @mmtftr
Created: 3/9/2026
Status: ❌ Closed

Base: main ← Head: feat/responses-tools

📝 Commits (4)

5d7e51a Support Responses API tool follow-ups
6059ef8 Fix Responses tool follow-up regressions
2db87b4 Normalize replayed Responses message ids
51b1448 Fix responses API continuation payload handling

📊 Changes

9 files changed (+2760 additions, -1132 deletions)

View changed files

📝 .gitignore (+1 -0)
📝 backend/open_webui/retrieval/loaders/main.py (+10 -7)
📝 backend/open_webui/routers/openai.py (+157 -47)
➕ backend/open_webui/test/util/test_middleware.py (+268 -0)
➕ backend/open_webui/test/util/test_misc.py (+194 -0)
➕ backend/open_webui/test/util/test_openai_router.py (+180 -0)
📝 backend/open_webui/utils/middleware.py (+425 -50)
📝 backend/open_webui/utils/misc.py (+151 -11)
📝 uv.lock (+1374 -1017)

📄 Description

Summary

This PR fixes Open WebUI's OpenAI Responses API follow-up flow so tool continuations reuse the upstream response state correctly instead of replaying malformed local history.

Issue And User Impact

Responses API conversations that included tool calls could fail or drift on the next turn. In practice, follow-up requests could resend placeholder assistant output, re-process already completed tool calls, or replay stored message items with ids that do not match the Responses API expectations. That made continuation payloads brittle and could surface as broken tool follow-ups, duplicated output blocks, or rejected follow-up requests after an earlier streamed response had already completed.

Root Cause

The middleware and router were still treating Responses API history too much like chat-completions history. We were not consistently anchoring follow-up requests on the latest persisted response_id, we were rebuilding continuation input from a larger local transcript than the API actually needs, and we were not normalizing replayed stored item ids before sending them back to OpenAI. During tool follow-ups, the streamed output buffer could also keep a local placeholder item and re-scan historical function calls instead of only the newly streamed delta.

Fix

The router now derives previous_response_id from the latest assistant message that carries a stored response id and only sends the delta suffix after that anchor. Stored Responses API output items are normalized before replay so function-call ids use the expected fc_ prefix and stored message ids use the expected msg_ prefix. The middleware now collapses prior Responses API history down to the current system message plus the incremental delta, trims the local continuation placeholder before appending follow-up output, preserves the already rendered output prefix when a continuation stream resumes, and extracts tool calls only from the newly streamed portion so previously completed calls are not re-issued.

Validation

I ran:

uv run pytest backend/open_webui/test/util/test_openai_router.py backend/open_webui/test/util/test_misc.py backend/open_webui/test/util/test_middleware.py

That suite passed with 21 tests covering response-id anchoring, continuation payload trimming, stored item id normalization, and Responses API tool follow-up handling.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/open-webui/open-webui/pull/22496 **Author:** [@mmtftr](https://github.com/mmtftr) **Created:** 3/9/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `feat/responses-tools` --- ### 📝 Commits (4) - [`5d7e51a`](https://github.com/open-webui/open-webui/commit/5d7e51a1dcb319c805a7ae9493fde388bcfaec68) Support Responses API tool follow-ups - [`6059ef8`](https://github.com/open-webui/open-webui/commit/6059ef80816952c02d33c38e5767af5722fff437) Fix Responses tool follow-up regressions - [`2db87b4`](https://github.com/open-webui/open-webui/commit/2db87b404d2614b3ba9ca92764a9ee5e6072c1ab) Normalize replayed Responses message ids - [`51b1448`](https://github.com/open-webui/open-webui/commit/51b1448775ed61d0835a0bb70b420ff8bff1b6d8) Fix responses API continuation payload handling ### 📊 Changes **9 files changed** (+2760 additions, -1132 deletions) <details> <summary>View changed files</summary> 📝 `.gitignore` (+1 -0) 📝 `backend/open_webui/retrieval/loaders/main.py` (+10 -7) 📝 `backend/open_webui/routers/openai.py` (+157 -47) ➕ `backend/open_webui/test/util/test_middleware.py` (+268 -0) ➕ `backend/open_webui/test/util/test_misc.py` (+194 -0) ➕ `backend/open_webui/test/util/test_openai_router.py` (+180 -0) 📝 `backend/open_webui/utils/middleware.py` (+425 -50) 📝 `backend/open_webui/utils/misc.py` (+151 -11) 📝 `uv.lock` (+1374 -1017) </details> ### 📄 Description ## Summary This PR fixes Open WebUI's OpenAI Responses API follow-up flow so tool continuations reuse the upstream response state correctly instead of replaying malformed local history. ## Issue And User Impact Responses API conversations that included tool calls could fail or drift on the next turn. In practice, follow-up requests could resend placeholder assistant output, re-process already completed tool calls, or replay stored message items with ids that do not match the Responses API expectations. That made continuation payloads brittle and could surface as broken tool follow-ups, duplicated output blocks, or rejected follow-up requests after an earlier streamed response had already completed. ## Root Cause The middleware and router were still treating Responses API history too much like chat-completions history. We were not consistently anchoring follow-up requests on the latest persisted `response_id`, we were rebuilding continuation input from a larger local transcript than the API actually needs, and we were not normalizing replayed stored item ids before sending them back to OpenAI. During tool follow-ups, the streamed output buffer could also keep a local placeholder item and re-scan historical function calls instead of only the newly streamed delta. ## Fix The router now derives `previous_response_id` from the latest assistant message that carries a stored response id and only sends the delta suffix after that anchor. Stored Responses API output items are normalized before replay so function-call ids use the expected `fc_` prefix and stored message ids use the expected `msg_` prefix. The middleware now collapses prior Responses API history down to the current system message plus the incremental delta, trims the local continuation placeholder before appending follow-up output, preserves the already rendered output prefix when a continuation stream resumes, and extracts tool calls only from the newly streamed portion so previously completed calls are not re-issued. ## Validation I ran: `uv run pytest backend/open_webui/test/util/test_openai_router.py backend/open_webui/test/util/test_misc.py backend/open_webui/test/util/test_middleware.py` That suite passed with 21 tests covering response-id anchoring, continuation payload trimming, stored item id normalization, and Responses API tool follow-up handling. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

GiteaMirror added the pull-request label 2026-05-16 00:24:32 -05:00

GiteaMirror closed this issue

2026-05-16 00:24:34 -05:00

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#97764