mirror of
https://github.com/diegosouzapw/OmniRoute.git
synced 2026-09-15 11:22:15 +03:00
65e81158ab
Landed with the design call resolved per the owner's pick — **option 1**: the synced store is now endpoint-agnostic (persistDiscoveredModels and managedModelImport no longer drop non-chat models at write time), and chat selectability moved to read time (auto-pool expansion in autoStrategy applies filterChatSelectableModels; the models-route projection already had its chatOnly filter). Your discovery test now passes end-to-end (3/3): /api/show capabilities persist per connection and image/embedding requests route through the advertising host. Reconciliation notes: conflicted areas merged onto the current tip (adobe discovery import, requestedModel preflight signature, resolvedProvider fast-path coexists with the synced-route override — explicit resolution wins); carried base-red drains (#10055 memoization, #11071 test variants) dropped as already-landed; the managed-model-import exclusion test was propagated to the new contract (image/video models persist; the read filter still hides them from chat pickers — pinned by a new assertion). Full battery: 205/206 focused (the one red is a confirmed periodic-timer timing flake on the loaded devbox — 20/20 isolated), autoCombo vitest 30/30, combo suites 46/46, gates + typecheck clean. Thank you @yourspraveen — the capability probe + routing design was right; it just needed the store contract opened up. Fixes #11087.
49 lines
2.3 KiB
TypeScript
49 lines
2.3 KiB
TypeScript
import test from "node:test";
|
|
import assert from "node:assert/strict";
|
|
|
|
const { shouldUseApiKeyConnectionTest } =
|
|
await import("../../src/app/api/providers/[id]/test/webSessionTestDispatch.ts");
|
|
|
|
test("normal API-key connections keep the API-key test path", () => {
|
|
assert.equal(shouldUseApiKeyConnectionTest("apikey", "openai"), true);
|
|
});
|
|
|
|
test("token-kind cookie-auth web sessions use the API-key test path", () => {
|
|
assert.equal(shouldUseApiKeyConnectionTest("cookie", "deepseek-web"), true);
|
|
|
|
assert.equal(shouldUseApiKeyConnectionTest("cookie", "zai-web"), true);
|
|
});
|
|
|
|
test("cookie-kind web sessions do not use the API-key test path", () => {
|
|
assert.equal(shouldUseApiKeyConnectionTest("cookie", "chatgpt-web"), false);
|
|
|
|
assert.equal(shouldUseApiKeyConnectionTest("cookie", "claude-web"), false);
|
|
});
|
|
|
|
test("token-kind web sessions WITHOUT a token-aware validator stay off the API-key test path", () => {
|
|
// hailuo-web and promptql are `kind: "token"` in WEB_SESSION_CREDENTIAL_REQUIREMENTS,
|
|
// but neither has an entry in validation.ts's SPECIALTY_VALIDATORS map (nor a
|
|
// token-aware branch like zai-web's in validateWebCookieProvider). Routing them through
|
|
// the API-key test path would dispatch to the generic cookie probe, which sends the
|
|
// stored token as a `Cookie` header and treats most non-401/403 responses as valid —
|
|
// an invalid hailuo-web/promptql token could be reported as a healthy connection.
|
|
assert.equal(shouldUseApiKeyConnectionTest("cookie", "hailuo-web"), false);
|
|
assert.equal(shouldUseApiKeyConnectionTest("cookie", "promptql"), false);
|
|
|
|
// Same reasoning applies to the other two token-kind providers with no validator.
|
|
assert.equal(shouldUseApiKeyConnectionTest("cookie", "microsoft-designer-web"), false);
|
|
assert.equal(shouldUseApiKeyConnectionTest("cookie", "t3-chat-web"), false);
|
|
});
|
|
|
|
test("every token-kind web session with a real token-aware validator uses the API-key test path", () => {
|
|
for (const providerId of ["deepseek-web", "kimi-web", "tinycms-web", "copilot-m365-web", "copilot-web", "zai-web"]) {
|
|
assert.equal(shouldUseApiKeyConnectionTest("cookie", providerId), true, providerId);
|
|
}
|
|
});
|
|
|
|
test("other auth types are not broadened", () => {
|
|
assert.equal(shouldUseApiKeyConnectionTest("oauth", "deepseek-web"), false);
|
|
|
|
assert.equal(shouldUseApiKeyConnectionTest(null, "deepseek-web"), false);
|
|
});
|