fix: base provider resolution - #5897
Merged
Merged
Conversation
|
tejas ghatte seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. You have signed the CLA already but the status is still pending? Let us recheck it. |
Contributor
📝 WalkthroughSummary by CodeRabbit
WalkthroughThe request path records each attempt’s base provider in ChangesReasoning ID context flow
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
TejasGhatte
marked this pull request as ready for review
August 6, 2026 10:59
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@core/bifrost.go`:
- Around line 6508-6509: Move the base provider assignment from shared
BifrostContext state into attempt-scoped response metadata, alongside the
existing RoutingInfo snapshot, and have chunk conversion—including
ShouldEmbedReasoningItemID—read that snapshot rather than the mutable context
key. Add a streaming fallback test using different base providers to verify
earlier chunks retain their original provider metadata.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: fdfe22cc-18a8-4015-ae5d-8c3ac2734843
📒 Files selected for processing (8)
core/bifrost.gocore/providers/anthropic/reasoningid_test.gocore/providers/anthropic/reasoningstream_test.gocore/providers/anthropic/responses.gocore/providers/utils/reasoningid_test.gocore/providers/utils/utils.gocore/schemas/account.gocore/schemas/bifrost.go
akshaydeo
approved these changes
Aug 6, 2026
Contributor
Merge activity
|
akshaydeo
pushed a commit
that referenced
this pull request
Aug 7, 2026
## Summary OpenAI models served through a custom provider (e.g. an `openai`-based custom provider with its own key like `"my-openai"`) were silently losing the reasoning item ID when converting to Anthropic thinking blocks. Because `ShouldEmbedReasoningItemID` matched against the raw provider key, custom providers never matched the `OpenAI` case and fell through to the default `false` arm — causing a mismatch OpenAI rejects with `"Encrypted content item_id did not match the target item id."`. ## Changes - Added `BifrostContextKeyBaseProviderType` context key, set during `requestWorker` to record the built-in provider backing each attempt. Custom providers surface their own key everywhere a `ModelProvider` is reported, so this gives downstream converters a way to resolve back to the underlying provider type. - Added `ResolveBaseProvider(ctx, provider)` helper in `schemas/account.go` that reads `BifrostContextKeyBaseProviderType` from the context and falls back to the raw provider key when the context carries none (direct converter calls, tests). - Updated `ShouldEmbedReasoningItemID` to accept a `*BifrostContext` and resolve through `ResolveBaseProvider` before switching on provider family. A custom provider wrapping OpenAI now qualifies unconditionally, matching native OpenAI behaviour — deployment-style model names used on OpenAI-compatible endpoints would never match an OpenAI-family model name check anyway. - Propagated the new `ctx` parameter through all call sites of `ShouldEmbedReasoningItemID` and `convertBifrostReasoningToAnthropicThinking`. ## Type of change - [x] Bug fix - [ ] Feature - [ ] Refactor - [ ] Documentation - [ ] Chore/CI ## Affected areas - [x] Core (Go) - [ ] Transports (HTTP) - [x] Providers/Integrations - [ ] Plugins - [ ] UI (React) - [ ] Docs ## How to test ```sh go test ./core/providers/anthropic/... ./core/providers/utils/... ./core/schemas/... ``` The new test `"openai-based custom provider embeds the id"` in `reasoningstream_test.go` directly covers the fixed path: it sets `BifrostContextKeyBaseProviderType` to `schemas.OpenAI` on the context while passing a custom provider key, and asserts the reasoning item ID is correctly embedded in the signature. `TestShouldEmbedReasoningItemID_NilContext` pins the nil-context fallback to ensure converters called outside a request context neither panic nor regress. ## Breaking changes - [ ] Yes - [x] No ## Related issues ## Security considerations None. The change only affects how a reasoning item ID is embedded into an opaque signature field passed between Anthropic-compatible clients and OpenAI backends. No auth, secrets, or PII are involved. ## Checklist - [x] I read `docs/contributing/README.md` and followed the guidelines - [x] I added/updated tests where appropriate - [x] I updated documentation where needed - [x] I verified builds succeed (Go and UI) - [x] I verified the CI pipeline passes locally if applicable
atharvamhaske
pushed a commit
to atharvamhaske/bifrost
that referenced
this pull request
Aug 13, 2026
## Summary OpenAI models served through a custom provider (e.g. an `openai`-based custom provider with its own key like `"my-openai"`) were silently losing the reasoning item ID when converting to Anthropic thinking blocks. Because `ShouldEmbedReasoningItemID` matched against the raw provider key, custom providers never matched the `OpenAI` case and fell through to the default `false` arm — causing a mismatch OpenAI rejects with `"Encrypted content item_id did not match the target item id."`. ## Changes - Added `BifrostContextKeyBaseProviderType` context key, set during `requestWorker` to record the built-in provider backing each attempt. Custom providers surface their own key everywhere a `ModelProvider` is reported, so this gives downstream converters a way to resolve back to the underlying provider type. - Added `ResolveBaseProvider(ctx, provider)` helper in `schemas/account.go` that reads `BifrostContextKeyBaseProviderType` from the context and falls back to the raw provider key when the context carries none (direct converter calls, tests). - Updated `ShouldEmbedReasoningItemID` to accept a `*BifrostContext` and resolve through `ResolveBaseProvider` before switching on provider family. A custom provider wrapping OpenAI now qualifies unconditionally, matching native OpenAI behaviour — deployment-style model names used on OpenAI-compatible endpoints would never match an OpenAI-family model name check anyway. - Propagated the new `ctx` parameter through all call sites of `ShouldEmbedReasoningItemID` and `convertBifrostReasoningToAnthropicThinking`. ## Type of change - [x] Bug fix - [ ] Feature - [ ] Refactor - [ ] Documentation - [ ] Chore/CI ## Affected areas - [x] Core (Go) - [ ] Transports (HTTP) - [x] Providers/Integrations - [ ] Plugins - [ ] UI (React) - [ ] Docs ## How to test ```sh go test ./core/providers/anthropic/... ./core/providers/utils/... ./core/schemas/... ``` The new test `"openai-based custom provider embeds the id"` in `reasoningstream_test.go` directly covers the fixed path: it sets `BifrostContextKeyBaseProviderType` to `schemas.OpenAI` on the context while passing a custom provider key, and asserts the reasoning item ID is correctly embedded in the signature. `TestShouldEmbedReasoningItemID_NilContext` pins the nil-context fallback to ensure converters called outside a request context neither panic nor regress. ## Breaking changes - [ ] Yes - [x] No ## Related issues ## Security considerations None. The change only affects how a reasoning item ID is embedded into an opaque signature field passed between Anthropic-compatible clients and OpenAI backends. No auth, secrets, or PII are involved. ## Checklist - [x] I read `docs/contributing/README.md` and followed the guidelines - [x] I added/updated tests where appropriate - [x] I updated documentation where needed - [x] I verified builds succeed (Go and UI) - [x] I verified the CI pipeline passes locally if applicable
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
3 participants
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.
Summary
OpenAI models served through a custom provider (e.g. an
openai-based custom provider with its own key like"my-openai") were silently losing the reasoning item ID when converting to Anthropic thinking blocks. BecauseShouldEmbedReasoningItemIDmatched against the raw provider key, custom providers never matched theOpenAIcase and fell through to the defaultfalsearm — causing a mismatch OpenAI rejects with"Encrypted content item_id did not match the target item id.".Changes
BifrostContextKeyBaseProviderTypecontext key, set duringrequestWorkerto record the built-in provider backing each attempt. Custom providers surface their own key everywhere aModelProvideris reported, so this gives downstream converters a way to resolve back to the underlying provider type.ResolveBaseProvider(ctx, provider)helper inschemas/account.gothat readsBifrostContextKeyBaseProviderTypefrom the context and falls back to the raw provider key when the context carries none (direct converter calls, tests).ShouldEmbedReasoningItemIDto accept a*BifrostContextand resolve throughResolveBaseProviderbefore switching on provider family. A custom provider wrapping OpenAI now qualifies unconditionally, matching native OpenAI behaviour — deployment-style model names used on OpenAI-compatible endpoints would never match an OpenAI-family model name check anyway.ctxparameter through all call sites ofShouldEmbedReasoningItemIDandconvertBifrostReasoningToAnthropicThinking.Type of change
Affected areas
How to test
go test ./core/providers/anthropic/... ./core/providers/utils/... ./core/schemas/...The new test
"openai-based custom provider embeds the id"inreasoningstream_test.godirectly covers the fixed path: it setsBifrostContextKeyBaseProviderTypetoschemas.OpenAIon the context while passing a custom provider key, and asserts the reasoning item ID is correctly embedded in the signature.TestShouldEmbedReasoningItemID_NilContextpins the nil-context fallback to ensure converters called outside a request context neither panic nor regress.Breaking changes
Related issues
Security considerations
None. The change only affects how a reasoning item ID is embedded into an opaque signature field passed between Anthropic-compatible clients and OpenAI backends. No auth, secrets, or PII are involved.
Checklist
docs/contributing/README.mdand followed the guidelines