fix(auth-profiles): break self-reinforcing session auth override loop (#85126)#85311
Closed
mlaihk wants to merge 1 commit into
Closed
fix(auth-profiles): break self-reinforcing session auth override loop (#85126)#85311mlaihk wants to merge 1 commit into
mlaihk wants to merge 1 commit into
Conversation
When a session falls back to a different provider (e.g. minimax → deepseek), the session entry stores the fallback provider's auth profile override (e.g. deepseek:default) with source 'auto'. On subsequent turns, resolveSessionAuthProfileOverride builds the auth profile order from the current run's provider (deepseek), not the agent's configured default model provider (minimax). Since deepseek:default is valid for deepseek's auth order, it's never re-evaluated against the agent's actual default model, creating a self-reinforcing loop. Fix: when source === 'auto', also include the agent's configured default model provider's auth profiles in the order list. This ensures the resolver can find and prefer the default model's auth profile when it's available, breaking the loop. Fixes openclaw#85126
openclaw-barnacle
Bot
added
agents
Contributor
|
Codex review: needs real behavior proof before merge. Reviewed June 24, 2026, 6:18 AM ET / 10:18 UTC. Summary PR surface: Source +29. Total +29 across 1 file. Reproducibility: yes. source-reproducible. Current main passes the already-selected provider into the auth-profile resolver, and the resolver returns only an auth profile id, so adding another provider's profile order can create a provider/auth mismatch. Review metrics: 1 noteworthy metric.
Stored data model Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Proof guidance:
Risk before merge
Maintainer options:
Next step before merge
Security Review findings
Review detailsBest possible solution: Recover stale fallback provider, model, display, and auth state together in session/model selection, while keeping the auth-profile resolver scoped to the active provider. Do we have a high-confidence way to reproduce the issue? Yes, source-reproducible. Current main passes the already-selected provider into the auth-profile resolver, and the resolver returns only an auth profile id, so adding another provider's profile order can create a provider/auth mismatch. Is this the best way to solve the issue? No. The PR is a plausible symptom fix, but provider, model, display, and auth need to recover together in session/model selection instead of broadening a provider-scoped auth helper. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against e9720c27fa69. Label changesLabel justifications:
Evidence reviewedPR surface: Source +29. Total +29 across 1 file. View PR surface stats
Security concerns:
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
|
clawsweeper
Bot
added
rating: 🧂 unranked krab
Contributor
|
ClawSweeper PR egg 🎁 Pass real behavior proof to wake the egg and unlock a hatchable treat. Where did the egg go?
|
Member
|
Heads up: this PR needs to be updated against current |
|
This assigned pull request has been automatically marked as stale after being open for 27 days. |
|
Closing due to inactivity. |
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.
Description
Fixes a self-reinforcing loop in
resolveSessionAuthProfileOverridethat permanently pins a session to the wrong auth profile after a fallback occurs.Root Cause
When a session falls back from its configured primary provider to a fallback (e.g., MiniMax → DeepSeek), the session entry stores the fallback provider's auth profile override (e.g.,
deepseek:default) withsource: "auto". On every subsequent turn,resolveSessionAuthProfileOverridebuilds the auth profile order exclusively from the current run's provider (the fallback, e.g.,deepseek), never from the agent's configured default model provider (e.g.,minimax). Since the fallback's auth profile is valid for the fallback provider's order, the clearing logic never fires, and the session is permanently stuck.Fix
When
source === "auto"(the override was set automatically via fallback), also include the agent's configured default model provider's auth profiles in the order list by prepending them. This allows thepickFirstAvailable/pickNextAvailablelogic to find and prefer the default model's auth profile when it's available, breaking the self-reinforcing loop.Testing
minimax/MiniMax-M2.7as primary anddeepseek/deepseek-v4-flashas fallback:deepseek:default. Auth order is["deepseek:default"]→ no alternative to pick.["minimax:global", "deepseek:default"]. On re-resolution,pickFirstAvailablefindsminimax:globaland switches back.Related
Fixes #85126 (supersedes the narrower issue description)
Related: #62412, #62710 (unmerged)