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

  1. Read the backend log line 'Admin-triggered ratification pass failed for user ...' — it carries the true exception
  2. Verify scheduler and FalkorDB services are up and reachable from the API process (docker compose ps, connection env vars)
  3. Fix or wait out the underlying cause, then retry the POST — the operation is stateless from the API side
  4. 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

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


AI-assisted analysis of Significant-Gravitas/AutoGPT@9c8bb5550f (2026-08-14). Data as JSON: /api/errors/e28302473fe861ee. Report an issue: GitHub.