Repository navigation
Conversation
The v1 provider schema had no `compatibility` field, so the block was silently dropped during config normalization and never reached models of `provider`+`npm`+`options` providers. Accept it on the v1 schema and carry it through migrateStandardProvider, merging an explicit block over the legacy setCacheKey derivation.
|
The following comment was made by an LLM, it may be inaccurate: |
![opencode-agent[bot]](https://avatars.githubusercontent.com/in/1549082?s=60&v=4){kind=small}
There was a problem hiding this comment.
Looks good. I reproduced #55652 on the base: the legacy provider shape returned compatibility: null from GET /api/model. With this change it returns { reasoningField: "reasoning_content" }, the same as the providers shape. With options.setCacheKey: true added, both values are kept. The Azure and Vertex-Anthropic migrations get the block too, because both build on migrateStandardProvider. The config normalization, provider and config tests pass, and typecheck in packages/core is clean.
Public API: the legacy config schema now accepts provider.<id>.compatibility (same shape as providers.<id>.compatibility). It used to be silently dropped. This is backwards compatible. If the block sets supportsPromptCacheKey itself, it takes precedence over options.setCacheKey.
No blocking concerns.
|
Thanks for the PR. We're closing it along with #55652: |
Issue for this PR
Closes #55652
Type of change
What does this PR do?
Custom providers declared with the legacy V1 shape (
provider+npm+options) lost theircompatibilityblock: the v1 provider schema has nocompatibilityfield, so config normalization silently dropped it and every model of the provider reachedGET /api/modelwithout it (e.g. a documentedcompatibility.reasoningFieldnever applied).packages/core/src/v1/config/provider.ts: accept the optionalcompatibilityblock on the v1 provider schema (sameProviderCompatibilityschema the v2 shape uses).packages/core/src/v1/config/migrate.ts: carry it throughmigrateStandardProvider; an explicit block keeps its fields and the legacysetCacheKeyderivation fills the rest (it still maps tosupportsPromptCacheKeyas before).How did you verify your code works?
packages/core/test/config/normalization.test.ts:supportsPromptCacheKey(from a legacysetCacheKey) and the explicitreasoningFieldcoexist.cd packages/core && bun test test/config/normalization.test.ts-> 38 pass / 0 failcd packages/core && bun test test/config/provider.test.ts test/config/config.test.ts-> 73 pass / 4 fail; the four failing cases areconfig.test.tsglobal-directory discovery, and they fail identically on a clean checkout ofdevwith this change stashed (pre-existing, unrelated).cd packages/core && bun run typecheck-> cleanScreenshots / recordings
Not a visual change.
Checklist
Added by the opencode bot (AI-generated).
Related: #52617, #55160
Public API: accepts
compatibilityon legacyprovider.<id>config entries (backwards compatible)