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
- Read the status in the message: 401/403 → re-authorize or refresh the connection's credentials in the dashboard.
- 429 → back off; stop polling quota frequently and let the existing quotaCache entry expire naturally.
- Re-check the connection's proxy settings if upstream calls are routed through a proxy that is down.
- 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
- Refresh connection credentials before quota polls when the token is near expiry.
- Throttle quota polling to stay under provider rate limits.
- Keep the last-good quota in cache for graceful degradation on 429/5xx.
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
- Failed to reset Codex limit
- Failed to load Codex reset credits
- `ClinePass token exchange failed: ${error}`
- `CodeBuddy state request failed: ${await response.text()}`
- `CodeBuddy Intl state request failed: ${await response.text(
AI-assisted analysis of decolua/9router@90b52e06ff (2026-08-30).
Data as JSON: /api/errors/2eb85cb0a132ff80.
Report an issue: GitHub.