Bug: Sub Agent tool fails with Unexpected response type: <class 'starlette.responses.PlainTextResponse'>

[nengoxx]

Issue:

When running the sub-agent with long tool calls and web searches the last response back to the original LLM throws "Unexpected response type: <class 'starlette.responses.PlainTextResponse'>"

Logs (had the debug option disabled sadly, I might update with the option on, takes a while to run the whole thing):

Here are the logs where I asked it to search for something:

log.txt

Additional info:

Apparently it only happened in the last iteration, or when it reaches max iterations. The sub-agent successfully created the research note I asked for, but since it threw the error, it started from scratch again with the main agent.

How to reproduce:

Currently testing it, but I just gave it a long research task with an elaborate prompt that maxed the sub-agent iterations while also writing a note.

For shorter tasks that go for lower steps, the agent seems to have no problem.

[Skyzi000]

Thanks for the detailed report and log — that was very helpful.

Root cause

When the upstream provider returns an HTTP error with a non-JSON body (HTML error pages from gateways/CDNs, plain-text rate-limit messages, etc.), Open WebUI core wraps it in starlette.responses.PlainTextResponse and forwards it to the caller. The Sub Agent loop only handled dict and JSONResponse, so the response fell through to a generic Unexpected response type: <PlainTextResponse> string. The parent agent saw an opaque message instead of the actual upstream status and body, which is likely why it restarted the task.

Fix

A new helper unwraps PlainTextResponse and other Starlette Response subclasses, so the upstream status, response type, and a truncated body preview now reach the parent agent in the tool result string.

Important caveat

This fix changes what error you see, not whether the error happens. The attached log shows cumulative tool result content of around 410k characters before the failing iteration, dominated by tool_search_and_scrape_post outputs. Tasks that accumulate large tool outputs may still hit provider-side limits regardless of this fix — context length, request size, or gateway timeout — only now the parent agent will see the actual reason in the tool result string instead of an opaque placeholder.

Note: the DEBUG valve in Sub Agent only adds extra logging for tool ID / terminal / direct-server resolution at startup. It does not log the chat completion response body, so enabling it will not surface the upstream error in the failing case. After upgrading, the diagnosis info comes through the tool result string itself.

Workarounds

• Lower MAX_ITERATIONS so cumulative tool output stays smaller.
• Narrow broad search/scrape calls, for example by reducing result counts or splitting the research into smaller sub-agent tasks.
• Use a model with a larger context window for tool-heavy tasks.

The fix is on the dev branch (Sub Agent v0.5.4) and will be included in the next release.