Significant-Gravitas/AutoGPT · error · HTTPException
Ratification pass failed: {type(exc).__name__}: {exc}
Error message
Ratification pass failed: {type(exc).__name__}: {exc} What it means
HTTP 500 raised when the synchronous ratification pass call get_scheduler_client().execute_ratification_pass_now(user_id=target) throws. Unlike the fire-and-forget endpoints there is no job row; the exception class name and message are embedded in the 500 detail and a warning with the target id prefix is logged.
Source
Thrown at autogpt_platform/backend/backend/api/features/admin/memory_admin_routes.py:845
target_id=target,
jwt_payload=jwt_payload,
)
try:
derive_group_id(target)
except ValueError as exc:
raise HTTPException(status_code=400, detail=str(exc))
try:
result = await get_scheduler_client().execute_ratification_pass_now(
user_id=target
)
except Exception as exc:
logger.warning(
"Admin-triggered ratification pass failed for user %s: %s",
target[:12],
exc,
)
raise HTTPException(
status_code=500,
detail=f"Ratification pass failed: {type(exc).__name__}: {exc}",
)
return RatificationResult.model_validate(result)
@router.post(
"/{user_id}/nightly",
response_model=JobTriggerResponse,
status_code=202,
)
async def trigger_nightly_batch(
request: Request,
user_id: Annotated[str, Path(description="User id or 'me'")],
caller_id: Annotated[str, Depends(get_user_id)],
jwt_payload: Annotated[dict, Security(get_jwt_payload)],
) -> JSONResponse:
"""Fire the full nightly batch fan-out and return 202 + job_id immediately.View on GitHub (pinned to 9c8bb5550f)
Solutions
- Read the backend log line 'Admin-triggered ratification pass failed for user ...' — it carries the true exception
- Verify scheduler and FalkorDB services are up and reachable from the API process (docker compose ps, connection env vars)
- Fix or wait out the underlying cause, then retry the POST — the operation is stateless from the API side
- If it persists, run the sweep manually via the scheduler to isolate whether the fault is in transport or in the pass logic
Defensive patterns
Strategy: try-catch
Try / catch
try:
result = await client.post(f"/memory/{uid}/ratification")
except httpx.HTTPStatusError as e:
if e.response.status_code == 500:
# detail embeds root exception type; check backend log for full cause
...
raise Prevention
- Ensure scheduler and FalkorDB are healthy before invoking the synchronous pass
- Expect this call to be slow — size client timeouts accordingly so you don't misread timeouts as 500s
- Alert on the 'Admin-triggered ratification pass failed' log line
When it happens
Trigger: POST /{user_id}/ratification passes validation, but the scheduler-side ratification sweep raises — scheduler service down/unreachable, FalkorDB/graph backend connection failure during the sweep, or an unexpected error inside the ratification logic itself.
Common situations: FalkorDB not running or wrong host/port credentials in graphiti config; scheduler running a different version whose RPC signature changed; transient DB timeouts during large sweeps; local dev where only part of docker-compose stack is up.
Related errors
- Dream pass scheduling failed: {type(exc).__name__}: {exc}
- Nightly batch scheduling failed: {type(exc).__name__}: {exc}
- Community rebuild scheduling failed: {type(exc).__name__}: {
- str(e)
- OpenAI API key not configured
AI-assisted analysis of Significant-Gravitas/AutoGPT@9c8bb5550f (2026-08-14).
Data as JSON: /api/errors/e28302473fe861ee.
Report an issue: GitHub.