fix(consumers): vendor config into the consumer LLM-client workflows - #2861
Conversation
PR #2850 fixed the `tools`-without-`config` sparse-checkout in the three root verifier workflows and hand-fixed one consumer template, but the guard it added only scanned `.github/workflows`. The consumer template directory it had just repaired was left unguarded, and two template workflows still vendored `tools` without `config`: - agents-issue-optimizer.yml runs scripts/langchain/issue_optimizer.py - agents-80-pr-event-hub.yml runs scripts/langchain/followup_issue_generator.py Both reach tools/langchain_client.py, which imports load_slot_config and configured_model_for_provider from tools/llm_registry.py. Those resolve config/llm_slots.json and config/model_registry.json relative to the vendored tree, and load_model_registry() returns [] when the file is absent, so the failure is a silent degradation to no configured model rather than an error. Extend the guard's discovery over templates/consumer-repo/.github/workflows so the consumer surface is covered the same way, and disambiguate the parametrize ids and assertion messages by full path now that a root workflow and a template workflow can share a basename.
Workflow source neededPR #2861 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. |
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 30 minutes Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughConsumer workflow sparse checkouts now include ChangesConsumer workflow coverage
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested labels: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 56dacfc53b
ℹ️ 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".
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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 `@templates/consumer-repo/.github/workflows/agents-80-pr-event-hub.yml`:
- Line 322: Add the required config entries in the manifest-managed source
workflow, then run synchronization to regenerate both templates:
templates/consumer-repo/.github/workflows/agents-80-pr-event-hub.yml:322-322 and
templates/consumer-repo/.github/workflows/agents-issue-optimizer.yml:129-129. Do
not edit either generated consumer workflow directly.
In `@tests/workflows/test_workflow_llm_installs.py`:
- Around line 34-44: Add the agents-80-pr-event-hub.yml workflow path to
KNOWN_LLM_CLIENT_WORKFLOWS, using the existing workflow-directory symbols, so
discovery includes it and runs the config test.
🪄 Autofix (Beta)
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: ASSERTIVE
Plan: Pro
Run ID: 4dfcde89-d845-45dd-aaa1-0d7a02c8f0a5
📒 Files selected for processing (3)
templates/consumer-repo/.github/workflows/agents-80-pr-event-hub.ymltemplates/consumer-repo/.github/workflows/agents-issue-optimizer.ymltests/workflows/test_workflow_llm_installs.py
Adding `config` to the consumer issue-optimizer sparse-checkout changes the template fingerprint the Health 74 Template Drift gate pins, so the pair became unallowlisted drift. Refresh template_sha256 and record why the divergence is deliberate: the root workflow runs in-tree where config/ is already present, so only the consumer template needs the extra entry.
Automated Status SummaryHead SHA: 368d520
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
|
2 participants
Why
Bounded closer follow-up to merged #2850, opened from its verifier disposition.
#2850's verifier returned unanimous PASS but anthropic flagged a recurrence risk: "if any other workflow vendors
toolsfrom stranske/Workflows withoutconfig(not covered here), the same bug could recur elsewhere — the added test appears designed to catch this going forward." Auditing that claim againstmainshowed it is real, and the gap is in the exact surface #2850 touched.#2850 fixed three root workflows and hand-fixed
templates/consumer-repo/.github/workflows/agents-verify-to-new-pr.yml. But the guard it added,_discover_llm_client_workflows(), scans onlyPath(".github/workflows"). The consumer template directory it had just repaired was left unguarded, so that hand-fix has no test protecting it and two sibling templates still carried the original defect:agents-issue-optimizer.ymlscripts/langchain/issue_optimizer.pyagents-80-pr-event-hub.ymlscripts/langchain/followup_issue_generator.pyBoth vendored
scripts/langchain+toolswithoutconfig.Why it matters
Both entry points reach
tools/langchain_client.py, which importsload_slot_configandconfigured_model_for_providerfromtools/llm_registry.py. Those resolve viaPath(__file__).resolve().parent.parent / "config" / ..., i.e. relative to the vendored tree — the same resolution #2850 diagnosed. Withconfigabsent,load_model_registry()logs a warning and returns[], so this degrades silently to no configured model rather than failing loudly.agents-80-pr-event-hub.ymlis the consumer-side verifier follow-up-issue path, so this ran unmodelled in every consumer repo.These workflows exist only in the template directory (the root repo runs the same scripts in-tree, where
config/is already present), which is why root-only discovery could not see them.Changes
templates/consumer-repo/.github/workflows/agents-issue-optimizer.yml— addconfigto thestranske/Workflowssparse-checkout.templates/consumer-repo/.github/workflows/agents-80-pr-event-hub.yml— same.tests/workflows/test_workflow_llm_installs.py— extend_discover_llm_client_workflows()overtemplates/consumer-repo/.github/workflowsas well, add both templates plus the already-fixedagents-verify-to-new-pr.ymltemplate toKNOWN_LLM_CLIENT_WORKFLOWS, and switch the parametrize ids and assertion messages frompath.nametopath.as_posix()now that a root workflow and a template workflow can share a basename.No behavior change to the root workflows and no change to
config/itself.Validation
agents-issue-optimizer.yml, the suite failed ontemplates/consumer-repo/.github/workflows/agents-80-pr-event-hub.yml— which a hand-maintained list would have missed, since a manual pass over the template directory had not flagged it.configfrom the issue-optimizer template again failstest_llm_workflows_vendor_the_model_registry_config[templates/consumer-repo/.github/workflows/agents-issue-optimizer.yml]; restoring it returns the gate to green.pytest tests/workflows/test_workflow_llm_installs.py— 29 passed, 2 skipped (both pre-existingagent-high-privilegeskips). Discovery now yields 6 workflows, up from 3.pytest tests/workflows— 651 passed, 6 skipped.ruff checkandblack --checkclean on the modified test file.Follow-on note
The template change reaches consumer repos through the normal
maint-68-sync-consumer-repos.ymlsync; no consumer-side action is needed here.Summary by CodeRabbit
Bug Fixes
Tests