fix: honor llm registry provider blocks - #2502
Conversation
📝 WalkthroughWalkthrough
ChangesOptional
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
Workflow source neededPR #2502 needs either a linked GitHub issue or one valid non-issue Workflow Source before PR metadata automation can manage it safely. Please do one of:
Once a valid source is present, this warning will not be reposted. |
Automated Status SummaryHead SHA: 4c66fa8
Coverage Overview
Coverage Trend
Top Coverage Hotspots (lowest coverage)
Low Coverage Files (<50.0%)
Updated automatically; will refresh on subsequent CI/Docker completions. Keepalive checklistScopeNo scope information available Tasks
Acceptance criteria
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 82ab8b1686
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| from langchain_openai import ChatOpenAI | ||
| except ImportError: | ||
| return None | ||
| chat_openai_cls = None |
There was a problem hiding this comment.
Sync the consumer template copies
This source change is consumer-facing, but the matching templates/consumer-repo/tools/langchain_client.py still returns immediately when langchain_openai is missing, and templates/consumer-repo/tools/llm_provider.py still converts a registry "" block signal back to the fallback model. Repos bootstrapped from templates/consumer-repo therefore keep the old behavior: Anthropic-only installs still fail client resolution and blocked fallback models can still be used. Please mirror these tools/ changes into the consumer template copies.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
tools/langchain_client.py (1)
293-299:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winGate OpenAI slot availability on
chat_openai_clsin auto-selection predicates.Lines 295 and 487 still treat OpenAI as available based only on
openai_token. Whenlangchain_openaiis missing butOPENAI_API_KEYis set, an unbuildable OpenAI slot can still be selected during prefiltering, which can skew slot/model override assignment inbuild_chat_clients.Suggested fix
@@ - slot.provider == PROVIDER_OPENAI and openai_token, + slot.provider == PROVIDER_OPENAI and openai_token and chat_openai_cls, @@ - slot.provider == PROVIDER_OPENAI and openai_token, + slot.provider == PROVIDER_OPENAI and openai_token and chat_openai_cls,Also applies to: 485-490
🤖 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 `@tools/langchain_client.py` around lines 293 - 299, The OpenAI slot availability check in the slot_available condition is missing a validation for the chat_openai_cls class, similar to how the Anthropic and GitHub slots check for their respective chat_*_cls classes. Update the condition checking slot.provider == PROVIDER_OPENAI to also verify that chat_openai_cls is available (not None) by adding and chat_openai_cls to the condition. This same issue also exists at lines 485-490 in another auto-selection predicate location, so both conditions need to be fixed to prevent unbuildable OpenAI slots from being selected during prefiltering.
🤖 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 `@tools/langchain_client.py`:
- Around line 293-299: The OpenAI slot availability check in the slot_available
condition is missing a validation for the chat_openai_cls class, similar to how
the Anthropic and GitHub slots check for their respective chat_*_cls classes.
Update the condition checking slot.provider == PROVIDER_OPENAI to also verify
that chat_openai_cls is available (not None) by adding and chat_openai_cls to
the condition. This same issue also exists at lines 485-490 in another
auto-selection predicate location, so both conditions need to be fixed to
prevent unbuildable OpenAI slots from being selected during prefiltering.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: f1173805-6614-489f-86f9-7e23200c555e
📒 Files selected for processing (4)
tests/tools/test_langchain_client.pytests/tools/test_llm_provider.pytools/langchain_client.pytools/llm_provider.py
🔗 Linked repositories identified
CodeRabbit considers these linked repositories for cross-repo context during reviews:
stranske/Template(auto-detected)stranske/Fine-Art-Archive(auto-detected)stranske/Ready(auto-detected)stranske/Workflows-Integration-Tests(auto-detected)
Summary
Validation
Summary by CodeRabbit
Bug Fixes
Tests