Significant-Gravitas/AutoGPT · critical · HTTPException

Rate limit reset failed and the automatic refund also failed

Error message

Rate limit reset failed and the automatic refund also failed. Please contact support for assistance.

What it means

HTTP 503 from POST /usage/reset (routes.py:1145). The worst branch of the failure ladder: the Redis daily-usage reset failed AND the automatic compensation refund (grant_credits) also raised, so the server logged 'CRITICAL: Failed to refund ... manual intervention required' (with exc_info) and returned 503. The user HAS been charged but did not receive the reset — money/state divergence requiring manual fix.

Source

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

                    "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,
        daily_cost_limit=daily_limit,
        weekly_cost_limit=weekly_limit,
        rate_limit_reset_cost=config.rate_limit_reset_cost,
        tier=tier,
    )

View on GitHub (pinned to 9c8bb5550f)

Solutions

Ops: grep backend logs for 'CRITICAL: Failed to refund' — the entry includes cost and user id[:8]; manually grant the refund to the affected user.
Verify Redis and the credit DB are both healthy before the user retries; a retry after recovery will charge again (the prior charge was not refunded).
Reconcile the user's transaction history (reason='CoPilot daily rate limit reset') against actual resets performed.
Add alerting on this log line — by design it demands human intervention.

Defensive patterns

Strategy: try-catch

Try / catch

try { await post('/chat/usage/reset'); } catch (e) {
  if (e.status === 503 && /contact support/.test(e.detail)) {
    // user WAS charged — capture tx id and file a support ticket, do NOT blind-retry
    await refreshBalance();
    openSupportTicket({ detail: e.detail });
    return;
  }
  throw e;
}

Prevention

Never auto-retry this 503 — the user was charged without receiving the reset
Surface the transaction to support immediately (server logged cost + user prefix)
Ops: alert on the 'CRITICAL: Failed to refund' log line and reconcile credits manually

When it happens

Trigger: Redis down for the reset AND the credit store (DB) failing for the refund — e.g. DB connection exhaustion or a transaction error inside grant_credits during a Redis brown-out; any Exception escaping the refund try block.

Common situations: Cascading infrastructure failure (Redis + DB pressure); partial outage where the credit service rejects grants. Rare, but when it fires the backend log carries the user id prefix (first 8 chars) and cost for reconciliation.

Related errors

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