Significant-Gravitas/AutoGPT · warning · HTTPException

No user found with the provided email.

Error message

No user found with the provided email.

What it means

HTTP 404 raised by the rate-limit admin helper _resolve_user_id when an email query parameter was supplied but get_user_by_email(email) returned no user. It fires before any rate-limit operation runs, and email takes precedence over user_id when both are given.

Source

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


class SetUserTierRequest(BaseModel):
    user_id: str
    tier: SubscriptionTier


async def _resolve_user_id(
    user_id: Optional[str], email: Optional[str]
) -> tuple[str, Optional[str]]:
    """Resolve a user_id and email from the provided parameters.

    Returns (user_id, email). Accepts either user_id or email; at least one
    must be provided.  When both are provided, ``email`` takes precedence.
    """
    if email:
        user = await get_user_by_email(email)
        if not user:
            raise HTTPException(
                status_code=404, detail="No user found with the provided email."
            )
        return user.id, email

    if not user_id:
        raise HTTPException(
            status_code=400,
            detail="Either user_id or email query parameter is required.",
        )

    # We have a user_id; try to look up their email for display purposes.
    # This is non-critical -- a failure should not block the response.
    try:
        resolved_email = await get_user_email_by_id(user_id)
    except Exception:
        logger.warning("Failed to resolve email for user %s", user_id, exc_info=True)
        resolved_email = None
    return user_id, resolved_email

View on GitHub (pinned to 9c8bb5550f)

Solutions

  1. Confirm the exact email in the User table (query Supabase/Prisma for the user)
  2. Trim whitespace and verify casing against the stored value
  3. If both email and user_id are known, pass the user_id to bypass email lookup
  4. Check you're connected to the correct environment's database

Example fix

// before
GET /api/rate_limit?email=jane.doe%20@example.com
// after
GET /api/rate_limit?email=jane.doe@example.com
Defensive patterns

Strategy: validation

Validate before calling

email = email.strip().lower()
assert email and "@" in email
# Prefer user_id when available to skip email lookup entirely

Try / catch

if resp.status_code == 404 and email_param:
    # email not found — verify spelling/environment before retry

Prevention

When it happens

Trigger: Calling an admin rate-limit endpoint (e.g. GET usage or POST reset) with ?email=... where the email has no User row in the database: typo'd address, unregistered user, wrong environment's database, or mixed-case/whitespace differences.

Common situations: Typo in the email (trailing spaces, '.con'); the target user exists in production but the admin tool points at a staging database; users who signed up via OAuth with a different canonical email; casing mismatch after email normalization changes.

Related errors


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