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

  1. 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
  2. Return a real 404 for unknown workflow_id rather than letting lookups raise
  3. Replace detail=str(e) with a static message such as 'Failed to get workflow status' and log the full traceback server-side
  4. 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

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.