fix: Check disabled state before AI Config mode mismatch#295
Draft
jsonbailey wants to merge 1 commit into
Draft
Conversation
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
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.
Bug
A disabled AI Config variation is served as
{"_ldMeta": {"enabled": false}}with nomodefield. InConfigFactory, each of the three builders (BuildCompletionConfig,BuildAgentConfig,BuildJudgeConfig) ran the mode-mismatch check before looking at theenabledflag. BecauseParseMetadefaults a missing mode to"completion", an agent or judge caller whose served variation was the disabled/off variation saw a spurious warning:The config wasn't a mode mismatch at all — it was simply disabled.
Fix
In all three builders, the disabled check now runs before the mode comparison. When the served variation is disabled (
enabled == false):LdAiCompletionConfig/LdAiAgentConfig/LdAiJudgeConfig) withenabled: false, carrying through the servedvariationKeyandversion.A minimal disabled config of the requested type is built rather than parsing the served body, since a disabled variation carries no model/messages/instructions. Null model/provider is safe — the base
LdAiConfigconstructor already coalesces them to empty defaults, matching how the SDK treats disabled configs elsewhere.The genuine mode-mismatch behavior for enabled configs whose mode truly differs is unchanged: it still warns and returns the caller's default. No public API changes.
Tests
Added two regression tests in
LdAiClientAgentJudgeTest: calling the agent and judge builders with a served{"_ldMeta": {"enabled": false}}(no mode) returns a disabled config of the requested type and emits no mode-mismatch warning. Existing mismatch tests (enabled config, wrong mode) continue to assert the warn-and-default path.Related
Companion changes are going up on branch
jb/disabled-config-mode-checkin:sdk-specs(spec change)js-core(companion SDK fix)