Significant-Gravitas/AutoGPT · error · HTTPException

Rate limit reset failed — please try again later. Your credi

Error message

Rate limit reset failed — please try again later. Your credits have not been charged.

What it means

HTTP 503 from POST /usage/reset (routes.py:1140). The flow charges credits first, then resets daily usage in Redis (reset_daily_usage). If the Redis reset fails, the endpoint compensates by refunding via grant_credits (a GRANT, not a Stripe TOP_UP). This message means the refund SUCCEEDED — the user was made whole — but the reset did not happen; a later retry is safe.

Source

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

                    cost,
                    "Refund for failed CoPilot rate-limit reset",
                )
                refunded = True
                logger.warning(
                    "Refunded %d credits to user %s after Redis reset failure",
                    cost,
                    user_id[:8],
                )
            except Exception:
                logger.error(
                    "CRITICAL: Failed to refund %d credits to user %s "
                    "after Redis reset failure — manual intervention required",
                    cost,
                    user_id[:8],
                    exc_info=True,
                )
            if refunded:
                raise HTTPException(
                    status_code=503,
                    detail="Rate limit reset failed — please try again later. "
                    "Your credits have not been charged.",
                )
            raise HTTPException(
                status_code=503,
                detail="Rate limit reset failed and the automatic refund "
                "also failed. Please contact support for assistance.",
            )

        # Track the reset count for daily cap enforcement.
        await increment_daily_reset_count(user_id)
    finally:
        await release_reset_lock(user_id)

    # Return updated usage status (public schema — percentages only).
    updated_usage = await get_usage_status(
        user_id=user_id,

View on GitHub (pinned to 9c8bb5550f)

Solutions

  1. Retry the reset once Redis is healthy — the refund restored the balance so a retry will charge again only if it proceeds further.
  2. Check Redis health and backend logs for 'CRITICAL: Failed to refund' absence (that would be the worse variant, error 150).
  3. Client-side: on 503 with this detail, refresh the balance display to reassure the user, then allow manual retry.
  4. Ops: alert on the reset-failure log path; frequent occurrences mean Redis durability issues are costing refunds.
Defensive patterns

Strategy: retry

Try / catch

try { await post('/chat/usage/reset'); } catch (e) {
  if (e.status === 503 && /credits have not been charged/.test(e.detail)) {
    await refreshBalance(); // reassure: refund already happened
    await sleep(30_000); return retryOnce();
  }
  throw e;
}

Prevention

When it happens

Trigger: Redis write fails (down, failover, eviction) exactly between the successful spend_credits call and reset_daily_usage; the refund path then completes. Any transient Redis fault during that window produces this 503.

Common situations: Redis restarts/OOM under load; connection blips; local dev with flaky Redis. Users see a scary 503 but their balance is intact — support should confirm balance before re-charging.

Related errors


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