capture resolved provider from the loadbalancer for logging

[akshaydeo]

Summary

When a routing layer selects a specific provider, CheckAndSetDefaultProvider was ignoring that selection and falling back to the route's default provider. This PR ensures that a routing-resolved provider takes precedence over the default, as long as it is still within the allowed set of available providers.

Changes

• Added a new context key BifrostContextKeyResolvedProvider to carry the provider selected by the routing layer.
• Updated CheckAndSetDefaultProvider to check for a resolved provider in context and return it immediately if it is present in the available providers list, before falling back to the default provider check.
• Added two tests: one verifying the resolved provider is used when allowed, and one verifying it is ignored when not in the available providers list.

Type of change

• Bug fix
• Feature
• Refactor
• Documentation
• Chore/CI

Affected areas

• Core (Go)
• Transports (HTTP)
• Providers/Integrations
• Plugins
• UI (React)
• Docs

How to test

go test ./core/providers/utils/... -run TestCheckAndSetDefaultProvider

Expected: both TestCheckAndSetDefaultProviderUsesResolvedProvider and TestCheckAndSetDefaultProviderIgnoresDisallowedResolvedProvider pass.

Breaking changes

• Yes
• No

Related issues

Security considerations

The resolved provider context key is explicitly marked DO NOT SET THIS MANUALLY and is only populated by the routing layer. It cannot be used to bypass available-provider constraints, as the check enforces membership in the allowed list before honoring the resolved provider.

Checklist

• I read docs/contributing/README.md and followed the guidelines
• I added/updated tests where appropriate
• I updated documentation where needed
• I verified builds succeed (Go and UI)
• I verified the CI pipeline passes locally if applicable

Summary by CodeRabbit

Release Notes

• Improvements

  • Enhanced provider selection logic to better utilize routing-determined providers when available.
  • Improved fallback behavior for provider resolution in routing scenarios.

• Tests

  • Added test coverage for provider selection scenarios with and without routing-resolved providers.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: f62810f2-21f2-48eb-9c74-4097a4d18cb2

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

📝 Walkthrough

Walkthrough

This PR adds support for routing-resolved provider selection in the provider utility layer. A new context key stores the resolved provider from routing, and the provider selection function now checks for and prioritizes this resolved provider when it is present in the available providers list.

Changes

Routing-Resolved Provider Selection

Layer / File(s)	Summary
Context key for routing-resolved provider core/schemas/bifrost.go	New BifrostContextKeyResolvedProvider constant defined to hold the routing-resolved ModelProvider in context.
Provider selection with resolved provider precedence core/providers/utils/utils.go, core/providers/utils/utils_test.go	CheckAndSetDefaultProvider updated with documentation and logic to check for a resolved provider in context; if present and contained in available providers, it is returned with a debug log; otherwise defaults to the existing selection order. Two tests validate precedence rules when the resolved provider is allowed and when it is disallowed.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Suggested reviewers

• danpiths

Poem

🐰 A routing path finds its way,
Through context keys that light the day,
Resolved providers claim their throne,
When allowed within the zone! 🐇

🚥 Pre-merge checks | ✅ 3 | ❌ 2

❌ Failed checks (2 warnings)

Check name	Status	Explanation	Resolution
Title check	⚠️ Warning	The title refers to capturing a resolved provider from the loadbalancer, which is only a supporting aspect of the main change—fixing a bug where CheckAndSetDefaultProvider was ignoring the routing-selected provider.	Update the title to emphasize the core bug fix, such as: 'Fix CheckAndSetDefaultProvider to respect routing-resolved provider selection'
Docstring Coverage	⚠️ Warning	Docstring coverage is 75.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description check	✅ Passed	The description is comprehensive, well-structured, covers all key aspects including summary, changes, testing, and security considerations with appropriate detail.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch 05-31-capture_resolved_provider_from_the_loadbalancer_for_logging

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[akshaydeo]

• coderabbit yml changes #3975
• handles compaction message type #3966
• openai integration content string handling #3949
• logs adds support for rendering file attachments #3931
• capture resolved provider from the loadbalancer for logging #3930 👈 (View in Graphite)
• restrict fallbacks and provider selection to vk boundry #3924
• azure dignotstic property strip for claude models #3925
• dev

This stack of pull requests is managed by Graphite. Learn more about stacking.

[greptile-apps]

Confidence Score: 5/5

Change is safe to merge — the new early-return is correctly guarded by the existing availableProviders check and cannot bypass the allowed-provider constraint.

The logic change is small and well-scoped: it only activates when BifrostContextKeyAvailableProviders is already set (non-nil, non-empty) and the resolved provider is a member of that list. All existing code paths are unchanged when the new key is absent. The two new tests cover both the resolution path and the bypass-prevention path.

No files require special attention.

Important Files Changed

Filename	Overview
core/schemas/bifrost.go	Adds BifrostContextKeyResolvedProvider constant with appropriate 'DO NOT SET THIS MANUALLY' annotation, consistent with adjacent reserved keys.
core/providers/utils/utils.go	Adds resolved-provider early-return inside CheckAndSetDefaultProvider; correctly scoped behind the availableProviders nil/empty guard, includes a debug log, and falls through to existing logic when the resolved provider is absent or not in the allowed set.
core/providers/utils/utils_test.go	Adds two focused unit tests covering both the happy path (resolved provider in allowed list) and the security path (resolved provider outside allowed list), both using the existing test helpers correctly.

_{Reviews (5): Last reviewed commit: "capture resolved provider from the loadb..." | Re-trigger Greptile}

[akshaydeo]

@coderabbitai full review

[coderabbitai]

✅ Actions performed

Full review triggered.

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

core/providers/utils/utils.go (1)

2946-2957: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Check the resolved provider before the skip-key-selection early return.

Line 2946 still returns defaultProvider before the new BifrostContextKeyResolvedProvider branch runs. That leaves a path where a routing-selected provider is ignored and the code falls back to the route default again.

Suggested fix

 func CheckAndSetDefaultProvider(ctx *schemas.BifrostContext, defaultProvider schemas.ModelProvider) schemas.ModelProvider {
 	if ctx != nil {
+		if ctx.Value(schemas.BifrostContextKeyAvailableProviders) != nil {
+			availableProviders, ok := ctx.Value(schemas.BifrostContextKeyAvailableProviders).([]schemas.ModelProvider)
+			if !ok || len(availableProviders) == 0 {
+				return ""
+			}
+			if resolvedProvider, ok := ctx.Value(schemas.BifrostContextKeyResolvedProvider).(schemas.ModelProvider); ok && slices.Contains(availableProviders, resolvedProvider) {
+				getLogger().Debug("[Provider] Using routing-resolved provider: %s (available: %v)", resolvedProvider, availableProviders)
+				return resolvedProvider
+			}
+		}
 		if skip, ok := ctx.Value(schemas.BifrostContextKeySkipKeySelection).(bool); ok && skip {
 			return defaultProvider
 		}
 		if ctx.Value(schemas.BifrostContextKeyAvailableProviders) != nil {
 			availableProviders, ok := ctx.Value(schemas.BifrostContextKeyAvailableProviders).([]schemas.ModelProvider)
 			if !ok || len(availableProviders) == 0 {
 				return ""
 			}
-			if resolvedProvider, ok := ctx.Value(schemas.BifrostContextKeyResolvedProvider).(schemas.ModelProvider); ok && slices.Contains(availableProviders, resolvedProvider) {
-				getLogger().Debug("[Provider] Using routing-resolved provider: %s (available: %v)", resolvedProvider, availableProviders)
-				return resolvedProvider
-			}
 			getLogger().Debug("[Provider] Available providers: %v, checking %s", availableProviders, defaultProvider)
 			if slices.Contains(availableProviders, defaultProvider) {
 				return defaultProvider
 			}
 			return availableProviders[0]
 		}

🤖 Prompt for 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.

In `@core/providers/utils/utils.go` around lines 2946 - 2957, The early return
that checks BifrostContextKeySkipKeySelection returns defaultProvider before
honoring a routing-resolved provider; modify the logic in the function that
reads ctx.Value so that you check for BifrostContextKeyResolvedProvider (and
verify it exists in the availableProviders using slices.Contains) before
performing the skip-key-selection early return (or, alternatively, if skip is
true, still inspect ctx.Value(schemas.BifrostContextKeyResolvedProvider) and
return it when present). Ensure you reference and preserve defaultProvider,
availableProviders (from
ctx.Value(schemas.BifrostContextKeyAvailableProviders)), the resolvedProvider
check (ctx.Value(schemas.BifrostContextKeyResolvedProvider)), and the
getLogger().Debug call so routing-resolved providers are used when available.

🤖 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.

Outside diff comments:
In `@core/providers/utils/utils.go`:
- Around line 2946-2957: The early return that checks
BifrostContextKeySkipKeySelection returns defaultProvider before honoring a
routing-resolved provider; modify the logic in the function that reads ctx.Value
so that you check for BifrostContextKeyResolvedProvider (and verify it exists in
the availableProviders using slices.Contains) before performing the
skip-key-selection early return (or, alternatively, if skip is true, still
inspect ctx.Value(schemas.BifrostContextKeyResolvedProvider) and return it when
present). Ensure you reference and preserve defaultProvider, availableProviders
(from ctx.Value(schemas.BifrostContextKeyAvailableProviders)), the
resolvedProvider check (ctx.Value(schemas.BifrostContextKeyResolvedProvider)),
and the getLogger().Debug call so routing-resolved providers are used when
available.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 247df19f-dc68-4084-83dc-7f9a32de7f98

📥 Commits

Reviewing files that changed from the base of the PR and between fe395bf and ed39e2d.

📒 Files selected for processing (3)

• core/providers/utils/utils.go
• core/providers/utils/utils_test.go
• core/schemas/bifrost.go

[akshaydeo]

Merge activity

• Jun 2, 8:41 AM UTC: A user started a stack merge that includes this pull request via Graphite.
• Jun 2, 8:43 AM UTC: @akshaydeo merged this pull request with Graphite.