Significant-Gravitas/AutoGPT · error · HTTPException

Unable to verify reset eligibility — please try again later.

Error message

Unable to verify reset eligibility — please try again later.

What it means

HTTP 503 from POST /usage/reset (routes.py:1056). Before allowing a paid reset the endpoint reads the user's daily reset count from Redis via get_daily_reset_count; that helper returns None when Redis is unavailable. The route deliberately fails closed (503) rather than letting the reset proceed without the cap counter, which would permit unlimited free resets during a Redis brown-out.

Source

Thrown at autogpt_platform/backend/backend/api/features/chat/routes.py:1056

    daily_limit, weekly_limit, tier = await get_global_rate_limits(
        user_id,
        config.daily_cost_limit_microdollars,
        config.weekly_cost_limit_microdollars,
    )

    if daily_limit <= 0:
        raise HTTPException(
            status_code=400,
            detail="No daily limit is configured — nothing to reset.",
        )

    # Check max daily resets.  get_daily_reset_count returns None when Redis
    # is unavailable; reject the reset in that case to prevent unlimited
    # free resets when the counter store is down.
    reset_count = await get_daily_reset_count(user_id)
    if reset_count is None:
        raise HTTPException(
            status_code=503,
            detail="Unable to verify reset eligibility — please try again later.",
        )
    if config.max_daily_resets > 0 and reset_count >= config.max_daily_resets:
        raise HTTPException(
            status_code=429,
            detail=f"You've used all {config.max_daily_resets} resets for today.",
        )

    # Acquire a per-user lock to prevent TOCTOU races (concurrent resets).
    if not await acquire_reset_lock(user_id):
        raise HTTPException(
            status_code=429,
            detail="A reset is already in progress. Please try again.",
        )

    try:
        # Verify the user is actually at or over their daily limit.

View on GitHub (pinned to 9c8bb5550f)

Solutions

1. Verify Redis health (docker compose ps / redis-cli ping) and connectivity from the backend host; restart the Redis service if needed.
2. Retry the request after Redis recovers — this 503 is transient and safe (no credits were charged at this point).
3. Add Redis uptime alerting; a pattern of these 503s indicates counter-store instability affecting the whole reset path.
4. If persistent, check REDIS connection settings (host/port/password) in backend env.

try { await post('/chat/usage/reset'); } catch (e) {
  if (e.status === 503) { await sleep(30_000); return retryWithBackoff(post, '/chat/usage/reset'); }
  throw e;
}

When it happens

Trigger: Redis is down/restarting/network-partitioned when the user calls /usage/reset and get_daily_reset_count returns None. Also hit in integration tests that stub get_daily_reset_count to return None.

Common situations: Redis container restarting or OOM-killed in docker compose; a Redis failover; connection pool exhaustion under load; local dev without Redis running.

Related errors

• Rate limit service degraded, retry shortly
• Rate limit reset failed — please try again later. Your credi
• Chat service degraded, retry shortly
• Rate limit reset is not available.
• No daily limit is configured — nothing to reset.

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