datawhalechina/hello-agents · error · HTTPException
str(e)
Error message
str(e)
What it means
This error is a catch-all 500 raised by the workflow-status endpoint in api/routes/workflow.py. The endpoint body only builds and returns a hardcoded mock status dict, so the except branch is effectively dead code; if it ever fires it means an unexpected runtime failure (e.g. logger misconfiguration or a refactor that added real logic) escaped the try block. The raw str(e) is leaked to the client, exposing internal details.
Source
Thrown at Co-creation-projects/Apricity-InnocoreAI/api/routes/workflow.py:304
except Exception as e:
logger.error(f"搜索和分析失败: {str(e)}")
raise HTTPException(status_code=500, detail=f"执行失败: {str(e)}")
@router.get("/status/{workflow_id}")
async def get_workflow_status(workflow_id: str):
"""获取工作流状态"""
try:
# 这里可以实现工作流状态跟踪
# 暂时返回模拟状态
return {
"workflow_id": workflow_id,
"status": "completed",
"progress": 100,
"message": "工作流已完成"
}
except Exception as e:
logger.error(f"获取工作流状态失败: {str(e)}")
raise HTTPException(status_code=500, detail=str(e))
View on GitHub (pinned to 606a07d341)
Solutions
- If you added real status-tracking code inside the try block, catch the specific exceptions (KeyError for unknown workflow_id, ConnectionError for the tracker) instead of a bare Exception
- Return a real 404 for unknown workflow_id rather than letting lookups raise
- Replace detail=str(e) with a static message such as 'Failed to get workflow status' and log the full traceback server-side
- Remove the try/except entirely if you keep the mock body — a dict literal cannot raise
Example fix
// before
except Exception as e:
logger.error(f"获取工作流状态失败: {str(e)}")
raise HTTPException(status_code=500, detail=str(e))
// after
except KeyError:
raise HTTPException(status_code=404, detail=f"Workflow '{workflow_id}' not found")
except Exception:
logger.exception("获取工作流状态失败")
raise HTTPException(status_code=500, detail="Failed to get workflow status") Defensive patterns
Strategy: try-catch
Validate before calling
// FastAPI client-side: none needed for the mock; if real tracking added, check id first
import requests
r = requests.get(f'{base}/workflow/{wid}/status')
if r.status_code == 404: raise KeyError(wid) Try / catch
try:
resp = client.get_workflow_status(workflow_id)
except HTTPError as e:
if e.response.status_code == 404:
handle_unknown_workflow(workflow_id)
else:
raise # 500: inspect server logs, do not retry blindly Prevention
- Do not rely on the mock 'completed' status in production — implement real tracking before integrating
- Treat any 500 from this route as a server defect: file it with the logged message instead of retrying
- Never forward detail strings from this endpoint to end users; they can contain internal exception text
When it happens
Trigger: Calling GET on the workflow status route (e.g. /workflow/{workflow_id}/status) in any circumstance where the dict construction or logging raises. With the current mock body, practically the only way to trigger it is a broken logger (logger is None) or an injected/modified implementation whose status-tracking code raises (DB connection failure, unknown workflow_id lookup, etc.).
Common situations: Developers extend the mock endpoint with real tracking (Redis/DB lookup) that throws; running with a misconfigured logging setup; calling the endpoint with an unexpected workflow_id after validation is added. Also hit during security reviews because the endpoint returns a fake 'completed' status for any id.
Related errors
AI-assisted analysis of datawhalechina/hello-agents@606a07d341 (2026-08-14).
Data as JSON: /api/errors/1ff42148b76c2fb3.
Report an issue: GitHub.