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 the

View on GitHub (pinned to 9c8bb5550f)

Solutions

  1. Retry after the Retry-After window (30s); once Redis is back the request re-evaluates normally.
  2. Ops: check Redis health/connectivity first — this error is an infrastructure signal, not a user-behavior signal.
  3. Client-side: distinguish 503 (retryable, show 'degraded') from 429 (not retryable, show limit UI); do not display 'limit reached' for this error.
  4. 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

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


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