Significant-Gravitas/AutoGPT · error · HTTPException

Failed to reset usage

Error message

Failed to reset usage

What it means

HTTP 500 raised when reset_user_usage(user_id, reset_weekly=...) throws during an admin rate-limit reset. The exception is logged with a traceback (logger.exception) and the response detail is the generic 'Failed to reset usage' — the real cause is only visible server-side. The usage snapshot that follows never runs.

Source

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

)
async def reset_user_rate_limit(
    user_id: str = Body(embed=True),
    reset_weekly: bool = Body(False, embed=True),
    admin_user_id: str = Security(get_user_id),
) -> UserRateLimitResponse:
    """Reset a user's daily usage counter (and optionally weekly). Admin-only."""
    logger.info(
        "Admin %s resetting rate limit for user %s (reset_weekly=%s)",
        admin_user_id,
        user_id,
        reset_weekly,
    )

    try:
        await reset_user_usage(user_id, reset_weekly=reset_weekly)
    except Exception as e:
        logger.exception("Failed to reset user usage")
        raise HTTPException(status_code=500, detail="Failed to reset usage") from e

    daily_limit, weekly_limit, tier = await get_global_rate_limits(
        user_id,
        config.daily_cost_limit_microdollars,
        config.weekly_cost_limit_microdollars,
    )
    usage = await get_usage_status(user_id, daily_limit, weekly_limit, tier=tier)
    multipliers = await get_tier_multipliers()

    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 UserRateLimitResponse(
        user_id=user_id,
        user_email=resolved_email,

View on GitHub (pinned to 9c8bb5550f)

Solutions

  1. Read the 'Failed to reset user usage' traceback in backend logs to identify the root cause
  2. Verify the usage-store (Redis) is reachable and credentials match
  3. Apply/run any pending migrations for usage key schemas, then retry
  4. Retry the reset after fixing the store; the operation is idempotent
Defensive patterns

Strategy: try-catch

Validate before calling

# Pre-flight: ping the usage/rate-limit store
assert await redis_client.ping(), "usage store unreachable; reset will fail"

Try / catch

try:
    resp = await client.post(reset_url)
except httpx.HTTPStatusError as e:
    if e.response.status_code == 500 and e.response.json()["detail"] == "Failed to reset usage":
        # generic detail: fetch root cause from backend logs (logger.exception)

Prevention

When it happens

Trigger: POST to reset a user's usage where the Redis/backend storing usage counters is unreachable, the key schema changed after a version upgrade, or a deserialization error occurs inside reset_user_usage (e.g. unexpected counter value shape).

Common situations: Redis down or restarting when the admin clicks 'reset'; auth/ACL mismatch between API and Redis after a config change; schema migration of usage keys not applied; ephemeral Redis in dev losing state mid-operation.

Related errors


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