Pin the prompt-cache provider gate against its class-name fallback - #61
Merged
Merged
Conversation
The gate reads the provider the factory stamped on the adapter and falls back to the adapter's own class name, which answers "openai" for the very class every unrecognized provider is routed to. Through the factory the stamp always decides and the fallback never runs, so a later edit to _provider_name could move which endpoints receive the fields without failing anything. Three tests state the matrix the gate is written against. A hand-built adapter carries no stamp and is taken at its class name, which is the intended reading: constructing OpenAIAdapter by hand says the request is bound for OpenAI's own endpoint, and the Azure subclass pins azure the same way. A stamped foreign provider closes the gate whichever class carries the stamp, which is the part a factory-built payload cannot show on its own, since the factory picks the class and writes the stamp together. And openrouter and xai, which the factory hands to their own builder, are pinned as receiving nothing. No behaviour change.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #60, tests only, no behaviour change.
The explicit prompt-cache fields are gated on the provider, and the gate reads the provider the factory stamped on the adapter, falling back to the adapter's own class name. That fallback answers "openai" for the very class every unrecognized provider is routed to. Through the factory the stamp always decides and the fallback never runs, so nothing in the suite depended on it and a later edit to
_provider_namecould have moved which endpoints receive the fields without failing a test.Three tests in
tests/models/test_openai_prompt_cache.pystate the matrix directly:OpenAIAdapterby hand says the request is bound for OpenAI's own endpoint, andAzureOpenAIAdapterpinsazurethe same way. Both name a surface the fields were measured on.xai,groq, an unknown gateway) closes the gate whichever class carries the stamp. A factory-built payload cannot show this on its own, since the factory picks the class and writes the stamp together.openrouterandxaithrough the factory, which route toOpenRouterAdapterand its own chat-completions body, receive nothing.Checked by mutation: dropping the stamp read fails 12 of the new cases, and dropping the fallback fails 76 across the file.
pytest tests/models -q: 871 passed, 39 skipped. No network anywhere in the file.