Significant-Gravitas/AutoGPT · error · HTTPException
Rate limit service degraded, retry shortly
Error message
Rate limit service degraded, retry shortly
What it means
HTTP 503 with Retry-After: 30 from POST /chat/stream (routes.py:1469). check_rate_limit raised RateLimitUnavailable because Redis could not report usage. The route deliberately fails CLOSED: as the comment states, the user may already be past their USD cap and the server cannot prove otherwise, so it returns 503 'degraded, retry shortly' rather than 429 'you hit your limit' or silently allowing the message.
Source
Thrown at autogpt_platform/backend/backend/api/features/chat/routes.py:1469
try:
daily_limit, weekly_limit, _ = await get_global_rate_limits(
user_id,
config.daily_cost_limit_microdollars,
config.weekly_cost_limit_microdollars,
)
await check_rate_limit(
user_id=user_id,
daily_cost_limit=daily_limit,
weekly_cost_limit=weekly_limit,
)
except RateLimitExceeded as e:
raise HTTPException(status_code=429, detail=str(e)) from e
except RateLimitUnavailable as e:
# Fail-closed on Redis brown-out: the user may already be at or
# past their USD cap and we cannot prove otherwise. 503 + a short
# Retry-After is the right UX (transient outage, retry shortly),
# not 429 ("you hit your limit").
raise HTTPException(
status_code=503,
detail="Rate limit service degraded, retry shortly",
headers={"Retry-After": "30"},
) from e
# Enrich message with file metadata if file_ids are provided.
# Also sanitise file_ids so only validated, workspace-scoped IDs are
# forwarded downstream (e.g. to the executor via enqueue_copilot_turn).
sanitized_file_ids: list[str] | None = None
if request.file_ids:
files = await resolve_workspace_files(user_id, request.file_ids)
sanitized_file_ids = [wf.id for wf in files] or None
request.message += build_files_block(files)
# Atomically append user message to session BEFORE creating task to avoid
# race condition where GET_SESSION sees task as "running" but message isn't
# saved yet. append_and_save_message returns None when a duplicate is
# detected — both the trailing-same-role check and theView on GitHub (pinned to 9c8bb5550f)
Solutions
- Retry after the Retry-After window (30s); once Redis is back the request re-evaluates normally.
- Ops: check Redis health/connectivity first — this error is an infrastructure signal, not a user-behavior signal.
- Client-side: distinguish 503 (retryable, show 'degraded') from 429 (not retryable, show limit UI); do not display 'limit reached' for this error.
- Alert on 503 rates from /chat/stream to catch Redis incidents early.
Defensive patterns
Strategy: retry
Try / catch
try { await post('/chat/stream', body); } catch (e) {
if (e.status === 503) { await sleep(Number(e.headers?.['retry-after'] ?? 30) * 1000); return retryOnce(); } // degraded, NOT limit-reached
throw e;
} Prevention
- Never render 'usage limit' UI for 503 — it means the limiter itself was unreachable
- Backoff-retry 503 with Retry-After; the check re-runs once Redis is back
- Alert on 503 rates from /chat/stream as a Redis incident canary
When it happens
Trigger: POST /chat/stream while Redis (usage counters) is unreachable — RateLimitUnavailable from check_rate_limit after get_global_rate_limits succeeded. Distinct from 429: the user's limits were never evaluated.
Common situations: Redis brown-out/restart during peak chat traffic; failover windows; dev environments with flaky Redis. All chat messages fail with 503 until Redis recovers.
Related errors
- Unable to verify reset eligibility — please try again later.
- Chat service degraded, retry shortly
- Rate limit reset failed — please try again later. Your credi
- You've reached your {window} usage limit. Resets in {time_st
- You've reached the limit of {resolved} active tasks (running
AI-assisted analysis of Significant-Gravitas/AutoGPT@9c8bb5550f (2026-08-14).
Data as JSON: /api/errors/f3f22561da65aeea.
Report an issue: GitHub.