Significant-Gravitas/AutoGPT · warning · HTTPException

User {request.user_id} not found

Error message

User {request.user_id} not found

What it means

HTTP 404 from the admin set-tier endpoint: resolving request.user_id's email returned None (email lookup wrapped in try/except that swallows to None on exception, so both 'no such user' and 'lookup infrastructure error' surface as this 404). The tier change is refused before old_tier is read.

Source

Thrown at autogpt_platform/backend/backend/api/features/admin/rate_limit_admin_routes.py:224

    request: SetUserTierRequest,
    admin_user_id: str = Security(get_user_id),
) -> UserTierResponse:
    """Set a user's rate-limit tier. Admin-only.

    Returns 404 if the user does not exist in the database.
    """
    try:
        resolved_email = await get_user_email_by_id(request.user_id)
    except Exception:
        logger.warning(
            "Failed to resolve email for user %s",
            request.user_id,
            exc_info=True,
        )
        resolved_email = None

    if resolved_email is None:
        raise HTTPException(status_code=404, detail=f"User {request.user_id} not found")

    old_tier = await get_user_tier(request.user_id)
    logger.info(
        "Admin %s changing tier for user %s (%s): %s -> %s",
        admin_user_id,
        request.user_id,
        resolved_email,
        old_tier.value,
        request.tier.value,
    )
    try:
        await set_user_tier(request.user_id, request.tier)
    except Exception as e:
        logger.exception("Failed to set user tier")
        raise HTTPException(status_code=500, detail="Failed to set tier") from e

    return UserTierResponse(user_id=request.user_id, tier=request.tier)

View on GitHub (pinned to 9c8bb5550f)

Solutions

  1. Confirm the user_id exists in the same database the API targets
  2. If the user should exist, check DB connectivity/logs — the 404 may mask a lookup exception
  3. Retry once after confirming health, since transient lookup failures present identically
  4. Cache-bust admin UI user lists so deleted users can't be selected for tier changes
Defensive patterns

Strategy: validation

Validate before calling

from uuid import UUID
uid = UUID(request_user_id)
assert await user_exists(uid), "user must exist before setting tier"

Try / catch

if resp.status_code == 404:
    # could be no-such-user OR a swallowed email-lookup exception — check DB health/logs

Prevention

When it happens

Trigger: POST the tier-set route with a request body user_id that has no User row — invalid/foreign UUID, deleted user — or when the email lookup throws (DB connectivity) and is swallowed to None, misreporting a live user as missing.

Common situations: Admin panel caches stale user ids after account deletion; environment mismatch (staging id against prod API); transient DB errors during the email lookup silently converted to 404; race where the user row is created after the tier call.

Related errors


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