Significant-Gravitas/AutoGPT · error · HTTPException

Failed to set tier

Error message

Failed to set tier

What it means

A 500 raised by the admin rate-limit endpoint when the underlying set_user_tier() call raises any exception while persisting a user's tier change. The route first logs the intended change, then wraps the persistence call; the HTTPException's 'Failed to set tier' detail hides the real cause, which is only visible in the logged traceback via logger.exception('Failed to set user tier'). It is a server-side persistence failure, not a client input problem.

Source

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

        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)


class UserSearchResult(BaseModel):
    user_id: str
    user_email: Optional[str] = None


@router.get(
    "/rate_limit/search_users",
    response_model=list[UserSearchResult],
    summary="Search Users by Name or Email",
)
async def admin_search_users(
    query: str,
    limit: int = 20,
    admin_user_id: str = Security(get_user_id),

View on GitHub (pinned to 9c8bb5550f)

Solutions

  1. Check backend logs for the logger.exception('Failed to set user tier') traceback — it carries the real root cause; fix that first (DB connectivity, missing row, bad enum value).
  2. Verify the user_id actually exists in the tier persistence store, not just in User search results; create the row or use the ensure/seed path if set_user_tier expects an existing record.
  3. Confirm request.tier is a valid UserTier enum value the persistence layer accepts (an invalid value may surface as a DB error rather than a 422).
  4. If the DB is down, restore connectivity (docker compose up postgres / check DATABASE_URL) and retry the admin call.

Example fix

// before
await set_user_tier(request.user_id, request.tier)  # 500 if user row is absent

// after
changed = await set_user_tier(request.user_id, request.tier)
if not changed:
    raise HTTPException(status_code=404, detail="User tier record not found")
Defensive patterns

Strategy: try-catch

Validate before calling

const user = await adminSearchById(request.user_id); // confirm a tier-store row exists
if (!user) throw new ClientError('user_id has no tier record');

Try / catch

try {
  await putAdminTier(userId, tier);
} catch (e) {
  if (e.status === 500) {
    // real cause is in backend logs (logger.exception 'Failed to set user tier')
    toast('Tier change failed on the server; check backend logs');
  } else throw e;
}

Prevention

When it happens

Trigger: PUT/PATCH to the admin tier-change route (rate_limit_admin_routes.py) with a valid user_id and tier after an admin auth check; set_user_tier throws — e.g. database unreachable, Prisma/Supabase error, user row missing in the tier store, or constraint violation during the update.

Common situations: Database connection pool exhausted or postgres container down; the user_id from the admin search endpoint does not exist in the table set_user_tier writes to (search reads the User table directly, so it can return users with no tier row); a migration changed the tier column and the enum value no longer maps.

Related errors


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