Skip to content

fix: Check disabled state before AI Config mode mismatch#295

Draft
jsonbailey wants to merge 1 commit into
mainfrom
jb/disabled-config-mode-check
Draft

fix: Check disabled state before AI Config mode mismatch#295
jsonbailey wants to merge 1 commit into
mainfrom
jb/disabled-config-mode-check

Conversation

@jsonbailey

Copy link
Copy Markdown
Contributor

Bug

A disabled AI Config variation is served as {"_ldMeta": {"enabled": false}} with no mode field. In ConfigFactory, each of the three builders (BuildCompletionConfig, BuildAgentConfig, BuildJudgeConfig) ran the mode-mismatch check before looking at the enabled flag. Because ParseMeta defaults a missing mode to "completion", an agent or judge caller whose served variation was the disabled/off variation saw a spurious warning:

AI Config mode mismatch for sample-agent: expected agent, got completion. Returning caller's default.

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):

  • No mode comparison runs and no "mode mismatch" warning is emitted.
  • The builder returns a disabled config of the requested type (LdAiCompletionConfig / LdAiAgentConfig / LdAiJudgeConfig) with enabled: false, carrying through the served variationKey and version.

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 LdAiConfig constructor 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-check in:

  • sdk-specs (spec change)
  • js-core (companion SDK fix)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant