decolua/9router · error · Error

HTTP ${response.status}: ${errorMsg}

Error message

HTTP ${response.status}: ${errorMsg}

What it means

When ProviderLimits fetches quota data for a connection and the upstream/API response is not OK, it throws `HTTP <status>: <errorMsg>` where errorMsg is extracted from the response body. This is the quota-fetch path's detailed failure message, distinguishing it from the generic connection-list error; it means the provider-specific quota endpoint (e.g. Codex/Anthropic usage APIs) rejected the request.

Source

Thrown at src/app/(dashboard)/dashboard/usage/components/ProviderLimits/index.js:261

        if (response.status === 401) {
          // Auth error - show message instead of throwing
          console.warn(
            `[ProviderLimits] Auth error for ${provider}:`,
            errorMsg,
          );
          const quotaEntry = {
            quotas: [],
            message: errorMsg,
          };
          setQuotaData((prev) => ({
            ...prev,
            [connectionId]: quotaEntry,
          }));
          setQuotaCache(connectionId, quotaEntry);
          return;
        }

        throw new Error(`HTTP ${response.status}: ${errorMsg}`);
      }

      const data = await response.json();
      console.log(`[ProviderLimits] Got quota for ${provider}:`, data);

      // Parse quota data using provider-specific parser
      const parsedQuotas = parseQuotaData(provider, data);

      const quotaEntry = {
        quotas: parsedQuotas,
        plan: data.plan || null,
        message: data.message || null,
        raw: data,
      };

      setQuotaData((prev) => ({
        ...prev,
        [connectionId]: quotaEntry,

View on GitHub (pinned to 90b52e06ff)

Solutions

  1. Read the status in the message: 401/403 → re-authorize or refresh the connection's credentials in the dashboard.
  2. 429 → back off; stop polling quota frequently and let the existing quotaCache entry expire naturally.
  3. Re-check the connection's proxy settings if upstream calls are routed through a proxy that is down.
  4. Verify the connection still exists and is enabled — deleted/disabled connections fail quota lookups.

Example fix

// before
throw new Error(`HTTP ${response.status}: ${errorMsg}`);
// after
if (response.status === 401 || response.status === 403) throw new Error(`Quota fetch unauthorized for ${provider} — re-authenticate this connection`);
throw new Error(`HTTP ${response.status}: ${errorMsg}`);
Defensive patterns

Strategy: fallback

Validate before calling

const cached = getQuotaCache(connectionId);
const cacheFresh = cached && Date.now() - cached.fetchedAt < 60_000;
if (cacheFresh) return cached.entry;

Type guard

const isQuotaPayload = (d) => d && typeof d === "object" && !Array.isArray(d);

Try / catch

try {
  const data = await fetchQuota(provider, connectionId);
  renderQuota(data);
} catch (e) {
  const m = /HTTP (\d+)/.exec(e.message);
  if (m && ["401", "403"].includes(m[1])) promptReauthorize(connectionId);
  else if (m && m[1] === "429") showStaleCachedQuota(connectionId);
  else showQuotaError(e.message);
}

Prevention

When it happens

Trigger: fetchQuota calls the provider quota API through the server and the response status is >= 400 — e.g. 401 when the connection's access token expired, 429 rate limit, or 403/404 from the upstream provider — after cached-fallback paths were exhausted, at ProviderLimits/index.js:261.

Common situations: Expired OAuth token for the provider connection; upstream provider rate-limiting quota polling; connection revoked on the provider side; proxy misconfiguration making the upstream call fail.

Related errors


AI-assisted analysis of decolua/9router@90b52e06ff (2026-08-30). Data as JSON: /api/errors/2eb85cb0a132ff80. Report an issue: GitHub.