Significant-Gravitas/AutoGPT · warning · HTTPException

A reset is already in progress. Please try again.

Error message

A reset is already in progress. Please try again.

What it means

HTTP 429 from POST /usage/reset (routes.py:1068). The reset flow is guarded by a per-user lock (acquire_reset_lock/release_reset_lock, released in the route's finally block) to prevent TOCTOU races where two concurrent requests both pass eligibility checks and double-charge credits. If the lock cannot be acquired because another reset is mid-flight for the same user, the second request gets 429 immediately.

Source

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

    # 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.
        # (rate_limit_reset_cost intentionally omitted — this object is only
        # used for limit checks, not returned to the client.)
        usage_status = await get_usage_status(
            user_id=user_id,
            daily_cost_limit=daily_limit,
            weekly_cost_limit=weekly_limit,
            tier=tier,
        )
        if daily_limit > 0 and usage_status.daily.used < daily_limit:
            raise HTTPException(
                status_code=400,
                detail="You have not reached your daily limit yet.",

View on GitHub (pinned to 9c8bb5550f)

Solutions

  1. Retry once after a short delay — the lock is released in the finally block as soon as the first request finishes.
  2. Fix the client: disable the submit button while the request is in flight and deduplicate (idempotency key or single-flight wrapper).
  3. Treat this 429 as transient contention, not as 'limit reached' — do not decrement any client-side reset counter.

Example fix

// before
<button onClick={() => post('/chat/usage/reset')}>Reset</button>

// after — single-flight the request
const [busy, setBusy] = useState(false);
<button disabled={busy} onClick={async () => {
  setBusy(true);
  try { await post('/chat/usage/reset'); }
  finally { setBusy(false); }
}}>Reset</button>
Defensive patterns

Strategy: retry

Validate before calling

// single-flight the reset button so a second request never races the first
if (resetInFlight) return;
resetInFlight = true;
try { await post('/chat/usage/reset'); } finally { resetInFlight = false; }

Try / catch

try { await post('/chat/usage/reset'); } catch (e) {
  if (e.status === 429 && /already in progress/.test(e.detail)) { await sleep(2_000); return retryOnce(); }
  throw e;
}

Prevention

When it happens

Trigger: Two near-simultaneous POST /usage/reset calls for the same user_id — e.g. double-click on the reset button, a frontend retry racing the original request, or duplicate submits from parallel tabs.

Common situations: UI without button disabling during in-flight requests; aggressive client retry on slow networks; test suites firing concurrent resets.

Related errors

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