fix(providers): test token-backed web sessions (#10519)

* fix(providers): test token-backed web sessions

* fix(providers): restrict token-web-session test dispatch to validated providers

Narrow shouldUseApiKeyConnectionTest to the token-kind web-session providers
that actually have a token-aware connection validator (deepseek-web, kimi-web,
tinycms-web, copilot-m365-web, copilot-web, zai-web). WEB_SESSION_CREDENTIAL_REQUIREMENTS
marks more providers as kind: "token" than have a matching validator in
SPECIALTY_VALIDATORS (hailuo-web, microsoft-designer-web, t3-chat-web, promptql) — those
were falling through to the generic cookie-based validateWebCookieProvider probe, which
sends the stored credential as a Cookie header and treats most non-401/403 responses as
valid, so an invalid token could be reported as a healthy connection.

Add regression coverage for hailuo-web and promptql (plus microsoft-designer-web and
t3-chat-web) proving they stay off the API-key test path, and for every currently
validated token-kind provider proving they still use it.

Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>

---------

Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
This commit is contained in:
Aman
2026-08-18 07:51:29 -06:00
committed by GitHub
parent 83c1d3c659
commit daae6e6fb5
4 changed files with 87 additions and 1 deletions

View File

@@ -27,6 +27,7 @@ import {
shouldFallbackToPublicCodeSuggestions,
} from "@/lib/oauth/gitlab";
import { providerAllowsOptionalApiKey } from "@/shared/constants/providers";
import { shouldUseApiKeyConnectionTest } from "./webSessionTestDispatch";
import { removeConnectionHealth } from "@omniroute/open-sse/services/apiKeyRotator.ts";
import { classifyAmbiguousOrAuthError, type ClassifyFailureArgs } from "./mistralAmbiguousAuth";
import { buildApiKeyConnectionTestResult } from "./apiKeyTestResult";
@@ -761,7 +762,7 @@ export async function testSingleConnection(connectionId: string, validationModel
refreshed: false,
diagnosis: (runtime as any).diagnosis,
};
} else if (connection.authType === "apikey") {
} else if (shouldUseApiKeyConnectionTest(connection.authType, provider)) {
const enrichedConnection = validationModelId
? {
...connection,

View File

@@ -0,0 +1,36 @@
import { getWebSessionCredentialRequirement } from "@/shared/providers/webSessionCredentials";
/**
* Token-kind web-session providers (`getWebSessionCredentialRequirement(...).kind ===
* "token"`) that actually have a token-aware connection validator wired up in
* `src/lib/providers/validation.ts`'s `SPECIALTY_VALIDATORS` map — either a dedicated
* `validate*WebProvider` entry, or (zai-web) a token-aware branch inside the generic
* `validateWebCookieProvider` probe (`src/lib/providers/validation/webCookie.ts`).
*
* `WEB_SESSION_CREDENTIAL_REQUIREMENTS` currently marks more providers as `kind: "token"`
* than have a matching validator (e.g. hailuo-web, microsoft-designer-web, t3-chat-web,
* promptql). Those fall through to `validateWebCookieProvider`'s generic probe, which
* sends the stored credential as a `Cookie` header and treats most non-401/403 responses
* as valid — the wrong wire format for a token-authenticated provider, so an invalid
* token can be reported as a healthy connection. Keep this set in sync with
* `SPECIALTY_VALIDATORS` (and the zai-web branch in `webCookie.ts`): add a provider here
* only after it has a real token-aware validator.
*/
const TOKEN_AWARE_VALIDATED_WEB_SESSION_PROVIDERS = new Set([
"deepseek-web",
"kimi-web",
"tinycms-web",
"copilot-m365-web",
"copilot-web",
"zai-web",
]);
export function shouldUseApiKeyConnectionTest(authType: unknown, providerId: unknown): boolean {
if (authType === "apikey") return true;
if (authType !== "cookie") return false;
if (getWebSessionCredentialRequirement(providerId)?.kind !== "token") return false;
return (
typeof providerId === "string" &&
TOKEN_AWARE_VALIDATED_WEB_SESSION_PROVIDERS.has(providerId)
);
}