lbjlaq/Antigravity-Manager · error · Error

apiKeyFun.errors.queryFailed

Error message

apiKeyFun.errors.queryFailed

What it means

runQuery() in src/pages/ApiKeyFun.tsx:244 throws this aggregate error when, after probing the transit endpoint, no usageSummary could be built: the sub2api `/usage` attempt (line 151), and the One-API/New-API fallback `/dashboard/billing/subscription` + `/dashboard/billing/usage` (lines 180-191) all failed or returned unparsable bodies. Each probe failure is swallowed with console.log, so this message is the only user-visible symptom. Note the `/models` fetch does NOT trigger it — a key with valid billing but empty models still succeeds. In web mode, an extra cause applies: `query_transit_info` is not in COMMAND_MAPPING, so request() throws error [1] for every probe and all of them are caught, leaving usageSummary null.

Source

Thrown at src/pages/ApiKeyFun.tsx:244

                            baseUrl: endpoint // optionally update baseUrl
                        };
                        return updated;
                    } else {
                        // Automatically save new key
                        return [{
                            id: crypto.randomUUID(),
                            key,
                            name: maskKey(key),
                            baseUrl: endpoint,
                            createdAt: now,
                            lastUsedAt: now,
                            lastStatus: 'ok',
                            lastRemaining: usageSummary?.remaining
                        }, ...prev];
                    }
                });
            } else {
                throw new Error(t('apiKeyFun.errors.queryFailed', { defaultValue: '无法获取有效的额度数据或模型列表,请确认 API Key 是否有效,以及接口地址是否正确。' }));
            }

        } catch (error: any) {
            console.error('Balance query failed', error);
            setQueryError(error?.message || 'Query failed. Please verify network or key validity.');
            setManagedKeys(prev => {
                const existingIndex = prev.findIndex(item => item.key === key);
                const now = Date.now();
                if (existingIndex >= 0) {
                    const updated = [...prev];
                    updated[existingIndex] = {
                        ...updated[existingIndex],
                        lastStatus: 'bad',
                        lastUsedAt: now,
                        baseUrl: endpoint
                    };
                    return updated;
                } else {

View on GitHub (pinned to a2e3c45423)

Solutions

  1. Confirm the endpoint manually: curl -H "Authorization: Bearer $KEY" "$ENDPOINT/usage" and "$ENDPOINT/dashboard/billing/subscription" — if both 404/401, the URL or key is wrong.
  2. In Web mode, add 'query_transit_info' to COMMAND_MAPPING in src/utils/request.ts (see error 1) — otherwise every probe silently fails and only this generic error appears.
  3. Include the per-endpoint failure details in the thrown message (modelsError / last billing error) instead of only the generic i18n text, so users can see which probe failed and why.
  4. Normalize the base URL before querying (strip trailing slashes, warn on missing scheme, optionally auto-retry with /v1 variant).

Example fix

// before (ApiKeyFun.tsx:243)
} else {
    throw new Error(t('apiKeyFun.errors.queryFailed', { defaultValue: '无法获取有效的额度数据或模型列表,请确认 API Key 是否有效,以及接口地址是否正确。' }));
}

// after: carry the concrete probe failure into the message
} else {
    const reason = modelsError || 'all billing endpoints (/usage, /dashboard/billing/*) failed';
    throw new Error(t('apiKeyFun.errors.queryFailed', {
        defaultValue: '无法获取有效的额度数据或模型列表,请确认 API Key 是否有效,以及接口地址是否正确。({{err}})',
        err: reason
    }));
}
Defensive patterns

Strategy: try-catch

Validate before calling

// Cheap pre-flight before the multi-endpoint probe
function validateQueryInputs(key: string, endpoint: string): string | null {
  if (!/^sk-[A-Za-z0-9_-]{8,}$/.test(key) && !/^[A-Za-z0-9_-]{16,}$/.test(key)) return 'key format looks invalid';
  try { new URL(endpoint); } catch { return 'endpoint is not a valid absolute URL'; }
  if (!/^https?:$/.test(new URL(endpoint).protocol)) return 'endpoint must be http(s)';
  return null;
}

const problem = validateQueryInputs(key, endpoint);
if (problem) { setQueryError(problem); return; }

Type guard

const isBillingPayload = (v: unknown): v is { remaining?: number; balance?: number; quota?: unknown; usage?: unknown } =>
  typeof v === 'object' && v !== null &&
  ('remaining' in v || 'balance' in v || 'quota' in v || 'usage' in v);

Try / catch

// Aggregate probe results so the user sees WHICH endpoint failed
const failures: string[] = [];
try { /* /usage probe */ } catch (e: any) { failures.push(`/usage: ${e?.message ?? e}`); }
try { /* /dashboard/billing/* probe */ } catch (e: any) { failures.push(`/dashboard/billing: ${e?.message ?? e}`); }
if (!usageSummary) {
  throw new Error(`${t('apiKeyFun.errors.queryFailed')} (${failures.join('; ') || 'no billing endpoints available'})`);
}

Prevention

When it happens

Trigger: Querying a key against a base URL that is not a sub2api/One-API/New-API compatible relay (e.g. pointing at an OpenAI-compatible endpoint that lacks billing routes); invalid/expired API key so /usage and /dashboard/billing/* return 401; wrong or truncated base URL (missing scheme, wrong port, trailing /v1 mismatch); CORS/network failure in web mode; query_transit_info unmapped in Web mode (see error 1).

Common situations: User pastes the console URL instead of the API base URL, or includes /v1 when the relay expects the bare domain; the relay is a custom implementation without dashboard billing endpoints; the key has no quota endpoints enabled; running the web deployment where the transit proxy command was never mapped.

Related errors


AI-assisted analysis of lbjlaq/Antigravity-Manager@a2e3c45423 (2026-08-16). Data as JSON: /api/errors/b6cae173c18c1844. Report an issue: GitHub.