test(FN-7690): reconcile anthropic-compatible apiType assertions + de-slow retry test
FN-7690 changed resolveApiType() to return the registered pi-ai key "anthropic-messages" for anthropic-compatible providers (the bare "anthropic" key is never registered and throws at stream time), but left behind a stale JSDoc and a stale test expectation: - custom-provider-registry.ts: update the FN-7689 buildCustomProviderModels comment that still described the anthropic/anthropic-messages drift as unresolved. - provider-registration.test.ts: assert config.api === "anthropic-messages" (was still asserting the pre-fix "anthropic"). Also de-slow a retry-exhaustion test: the describe uses fake timers with shouldAdvanceTime, so awaiting a 3-retry backoff (1s+5s+15s) burned ~21s of real wall time. Drive the backoff with advanceTimersByTimeAsync instead (Standing Rule: prefer fake timers over real time waits). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -259,7 +259,11 @@ describe("registerCustomProviders anthropicPromptCaching opt-in (FN-7689)", () =
|
||||
const call = modelRegistry.registerProvider.mock.calls.find(([key]: [string]) => key === "acme-ai");
|
||||
expect(call).toBeDefined();
|
||||
const [, config] = call as [string, { api: string; models: Array<{ compat?: Record<string, unknown> }> }];
|
||||
expect(config.api).toBe("anthropic");
|
||||
// FNXC:ProviderAuth 2026-07-08-17:50: anthropic-compatible resolves to the
|
||||
// registered pi-ai key "anthropic-messages" (FN-7690), not the bare
|
||||
// "anthropic" key which is never registered and throws at stream time.
|
||||
// Reconciles FN-7689's stale pre-FN-7690 expectation.
|
||||
expect(config.api).toBe("anthropic-messages");
|
||||
expect(config.models[0].compat).toBeUndefined();
|
||||
});
|
||||
|
||||
|
||||
@@ -57,10 +57,11 @@ export function resolveApiType(apiType: string): string {
|
||||
* FN-7689: shared model-list builder used by BOTH custom-provider registration paths
|
||||
* (this module's `toProviderConfig` and pi.ts's `createFnAgent` inline registration) so the
|
||||
* `compat.cacheControlFormat` opt-in cannot drift between them again. `api` is the pi-ai
|
||||
* api-registry key resolved by each call site's own resolver — `resolveApiType` here returns
|
||||
* `"anthropic"` while pi.ts's `resolveCustomProviderApiType` returns `"anthropic-messages"` for
|
||||
* the same `anthropic-compatible` input (a pre-existing naming drift out of scope for this fix;
|
||||
* see FN-7689 follow-up). Only `"openai-completions"` gets `compat.cacheControlFormat` — pi-ai's
|
||||
* api-registry key resolved by each call site's own resolver — both `resolveApiType` here and
|
||||
* pi.ts's `resolveCustomProviderApiType` return `"anthropic-messages"` for the same
|
||||
* `anthropic-compatible` input (FN-7690 reconciled the earlier naming drift; the bare
|
||||
* `"anthropic"` key is never registered by pi-ai). Only `"openai-completions"` gets
|
||||
* `compat.cacheControlFormat` — pi-ai's
|
||||
* anthropic path already auto-caches without any flag, and `openai-responses` uses OpenAI's
|
||||
* native `prompt_cache_key`/`prompt_cache_retention` mechanism (no `cache_control` marker concept
|
||||
* per pi-ai's `OpenAIResponsesCompat`), so the opt-in is inert there by construction.
|
||||
|
||||
Reference in New Issue
Block a user