From 91fb33ef576124d9dae25d32f0481207c974c160 Mon Sep 17 00:00:00 2001 From: Classic298 <27028174+Classic298@users.noreply.github.com> Date: Sun, 27 Sep 2026 21:11:20 +0200 Subject: [PATCH] fix(retrieval): name the link when process/url cannot fetch it (#31354) Attaching a link in chat or to a knowledge base that cannot be fetched (closed port, blocked by the fetch filter, an HTTP error such as 404) showed the toast "Error processing URL", which never said which link failed or that fetching it was the problem. The fetch step now answers with "Could not read content from ", the same message process/web gives for a link it cannot read, so both endpoints report a dead link the same way. The too-large 413 still passes through unchanged, and a working link returns exactly what it did before. The new handler covers only the fetch. Rewording the endpoint's existing catch-all would be one line, but that handler also receives database errors from the config and file lookups, which would then be reported as an unreadable link. Related to #31347 --- backend/open_webui/routers/retrieval.py | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/backend/open_webui/routers/retrieval.py b/backend/open_webui/routers/retrieval.py index 6517ed0674..e5a959f663 100644 --- a/backend/open_webui/routers/retrieval.py +++ b/backend/open_webui/routers/retrieval.py @@ -2376,7 +2376,16 @@ async def process_url( } config = await get_retrieval_config() - url_result = await _fetch_url(form_data.url, config.FILE_MAX_SIZE) + try: + url_result = await _fetch_url(form_data.url, config.FILE_MAX_SIZE) + except HTTPException: + raise + except Exception as e: + log.exception(e) + raise HTTPException( + status_code=status.HTTP_400_BAD_REQUEST, + detail=ERROR_MESSAGES.DEFAULT(e, f'Could not read content from {form_data.url}'), + ) if url_result['kind'] == 'web': result = await process_web(request, form_data, process=process, user=user)