Repository navigation
fix: avoid repeated xAI OAuth refresh during discovery - #140434
Conversation
|
🦞👀 Pull request received. I will update this pull request when review starts. ClawSweeper review completeClawSweeper finished reviewing this revision. The review result is being finalized. |
|
Codex review: needs maintainer review before merge. Reviewed September 6, 2026, 5:30 PM ET / 21:30 UTC. ClawSweeper reviewWhat this changesThe xAI plugin stops repeating failed OAuth refresh attempts during model discovery while preserving API-key fallbacks, with expanded planner regression coverage. Merge readiness✅ Ready for maintainer review This remains a useful, focused fix: current main still repeats credential resolution after OAuth preparation fails. No blocking correctness findings were found, and the maintainer-authored PR is protected from automated closure. Priority: P2 Review scores
Verification
How this fits togetherModel discovery prepares provider credentials before asking the xAI plugin for available models. Its results and failure outcomes feed OpenClaw’s model inventory and determine whether compatible previously discovered models remain available. flowchart TD
A[Model refresh request] --> B[Prepare ordered credentials]
B --> C{xAI authentication result}
C -->|Preparation exhausted| D[Report unavailable and retain compatible inventory]
C -->|Usable credential| E[Resolve selected authentication]
E --> F[Fetch xAI model catalog]
F --> G[Publish model inventory]
Before mergeNone. Agent review detailsSecurityNone. PR surfaceSource +5, Tests +48. Total +53 across 2 files. View PR surface stats
Review metricsNone. Technical reviewBest possible solution: Keep xAI discovery bound to prepared authentication, preserve usable fallbacks, and retain compatible inventory when preparation is exhausted. Do we have a high-confidence way to reproduce the issue? Yes, source establishes the path: failed OAuth preparation excludes a profile, but current main’s xAI hook reopens implicit profile resolution. The PR reports matching Gateway before/after probes; this review did not execute them. Is this the best way to solve the issue? Yes. The patch honors the existing preparation contract using an existing resolver option, with coverage for exhausted profiles and all three API-key fallback sources. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning medium; reviewed against c2941a8db981. LabelsLabel justifications:
EvidenceWhat I checked:
Likely related people:
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
HistoryReview history (1 earlier review cycle)
|
|
Fixed: xAI model discovery no longer repeats failed OAuth refresh attempts while retaining valid API-key fallback. |
* commit '294df333c58f2da104eccffc623ccb3c4d43d4d8': (1802 commits) fix: clear stale diagnostics after Gateway changes (#140426) fix: keep plugin catalogs intact after discovery timeouts (#140441) perf(tui): prepare session picker rows once per overlay (#140462) refactor(config): reuse environment substitution for write-back (#140460) refactor(discord): remove retired auto-presence templates (#140463) fix(ui): finish roster refreshes during session activity (#140459) fix(setup): match prepared credentials to the model provider (#140461) fix: keep MiniMax discovery on the selected credential (#140438) refactor(tests): remove unused parent context cache reset (#140456) fix: avoid repeated xAI OAuth refresh during discovery (#140434) perf(routing): reuse prepared event session targets (#140454) fix(media): keep deferred audio and extraction providers discoverable (#139231) refactor(codex): remove redundant app-server forwarding (#140451) fix(test): avoid false native polling timeouts (#140119) test(gateway): retain saved source in reload fixtures (#140453) fix(gateway): reduce repeated model work when listing sessions (#140414) fix(feishu): fall back to post mode over table limit (#136382) fix: use the bundle-compatible Proxyline runtime under Bun (#140411) refactor(trace): reuse the canonical usage counter type (#140444) refactor(node-host): share execution policy result fields (#140446) ...
Prevent duplicate failed xAI OAuth refresh requests during model discovery while preserving valid API-key fallback and profile-scoped failure outcomes.
Related: #137120
What Problem This Solves
Fixes an issue where refreshing xAI models could resend an OAuth refresh request after credential preparation had already failed. This also happened when a usable configured API key was available as the fallback. Repeating an ambiguous failed refresh is unsafe for rotating tokens.
Why This Change Was Made
The xAI catalog now honors exhausted preparation and keeps a prepared environment or configuration fallback from reopening implicit profile selection. It uses the existing runtime auth option for direct fallback attempts; selected stored profiles and genuinely absent catalog auth retain their existing resolution paths.
User Impact
Model discovery does not repeat failed OAuth preparation. Valid stored, configured, and environment API-key fallbacks still work, and failed discovery retains its existing profile-scoped outcomes and compatible-inventory behavior. No new settings, dependencies, schema changes, or session-pin policy are introduced.
Evidence
e1c1bc37c77f527c4c33b2dc3dd054f0886e1fdc, the real planner and registered xAI plugin made two refresh attempts for one exhausted profile and four for two. The configured-key fallback also refreshed the failed profile twice. Stored-key fallback controls passed.models.listcalls against temporary SQLite auth stores reproduce two failed refresh requests per profile before the fix and one after it. Matched before/after cases cover an ambiguous transport disconnect, two profiles returning HTTP 503, and a usable configured API-key fallback. The fallback still makes one correctly authenticated model request and reports ready.The runtime probes use synthetic credentials and controlled loopback HTTPS through a managed proxy. They establish request count, credential selection, and runtime behavior, not vendor credential acceptance. No provider API contract changes.