opendatalab/MinerU · error · HTTPException
{detail}
Error message
{detail} What it means
HTTPException that re-raises the upstream's non-200 status and body verbatim when fetching a task result. The upstream response body (or reason phrase if empty) becomes the error detail, and the failure is recorded on the task record.
Source
Thrown at mineru/cli/router.py:1320
"GET",
result_url,
timeout=build_result_download_timeout(),
),
stream=True,
)
except httpx.HTTPError as exc:
await request.app.state.router_task_registry.increment_upstream_error(task.task_id, str(exc))
raise HTTPException(status_code=502, detail=str(exc)) from exc
if upstream_response.status_code != 200:
body = await upstream_response.aread()
await upstream_response.aclose()
detail = body.decode("utf-8", errors="replace").strip() or upstream_response.reason_phrase
await request.app.state.router_task_registry.increment_upstream_error(
task.task_id,
f"{upstream_response.status_code} {detail}",
)
raise HTTPException(
status_code=upstream_response.status_code,
detail=detail,
)
content_type = upstream_response.headers.get("content-type", "")
if "application/json" in content_type:
body = await upstream_response.aread()
await upstream_response.aclose()
return Response(
content=body,
status_code=200,
media_type="application/json",
)
headers: dict[str, str] = {}
content_disposition = upstream_response.headers.get("content-disposition")
if content_disposition:
headers["content-disposition"] = content_dispositionView on GitHub (pinned to 4fe4bde114)
Solutions
- Read the status code and detail — they come straight from the upstream result endpoint
- If 404 upstream: the result no longer exists there (restart/eviction); re-submit the task
- Check upstream logs for the matching request; fix upstream result retention/storage if results vanish
Defensive patterns
Strategy: try-catch
Try / catch
r = client.get(f"{router}/tasks/{task_id}/result")
if r.status_code == 404:
resubmit(files) # upstream lost the result; nothing to fetch
elif r.status_code >= 500:
retry_with_backoff(lambda: client.get(f"{router}/tasks/{task_id}/result")) Prevention
- Archive results client-side immediately after download; upstream result storage is transient
- Distinguish upstream-originated statuses (pass-through) from router 502s: retry only transient classes
- Enable durable result storage on the upstream if restarts are frequent
When it happens
Trigger: GET {upstream}/tasks/{id}/result returns e.g. 404 (result evicted upstream), 403, or 500; the router reads the body, closes the stream, and returns the same status/detail to the client.
Common situations: Upstream restarted and lost the finished result; result retention on the upstream expired; upstream error during result assembly. The status code is upstream's, so it identifies the true cause.
Related errors
- {exc.detail}
- No healthy upstream MinerU API servers are available
- MinerU upstream returned an invalid submit payload
- Invalid submit payload: {exc}
- Unknown process_mode: {process_mode}
AI-assisted analysis of opendatalab/MinerU@4fe4bde114 (2026-08-14).
Data as JSON: /api/errors/4bc928acbebbf6fd.
Report an issue: GitHub.