Skip to content

[bug] Make model list and config-get outputs JSON-safe #2120

Description

@zerob13

Summary

The current dev build returns internal_error: Route returned an invalid result for model list and model config-get, including across unrelated providers. The route result passes its domain schema but fails the CLI server's pure-JSON validation.

Priority: P1 for CLI administration and diagnostics

Reproduction

The following public commands fail after successful provider/model resolution:

deepchat model list --provider <provider> --json
deepchat model config-get --provider <provider> --model <model> --json

The behavior reproduces with more than one built-in provider, so it is not provider-specific.

Root cause

The failure occurs in the boundary between route schemas and the CLI JSON envelope:

  • modelsListRuntimeRoute in src/shared/contracts/routes/models.routes.ts contains model objects with many optional fields.
  • src/main/provider/routes.ts returns providerRuntime.getModelList() through that schema.
  • PublicModelConfigSchema also contains optional configuration fields.
  • CliServer.parseRouteOutput() in src/main/cli/server.ts first parses the route output and then parses the result with JsonValueSchema.

Zod preserves an optional key when the input object explicitly contains that key with value undefined. Such an object passes the model/config schema but is not a valid JSON value, causing the second parse to fail.

This explanation matches both failing routes and was independently reproduced with the same Zod optional-field behavior. The exact offending key should still be captured in a safe regression test rather than logged with values.

Related contracts and documentation

  • docs/architecture/local-control-plane/spec.md requires canonical typed routes, deterministic JSON/JSONL, and stable machine-mode envelopes.
  • It explicitly requires safe/redacted public DTOs and rejects a second loosely defined CLI-only schema.
  • Public model configuration is intended to reject or strip unsupported fields while remaining JSON serializable.

Impact

  • CLI users cannot enumerate runtime models or inspect effective model configuration.
  • Provider diagnosis and benchmark setup are blocked.
  • The generic error does not identify a schema path, making regressions hard to isolate.
  • Renderer IPC can appear healthy while the public CLI contract is broken.

Proposed direction

  • Introduce an explicit JSON-safe DTO projection that omits every undefined property before public route output.
  • Prefer field-by-field public mapping over generic serialization that could accidentally expose extra provider metadata.
  • Add secret-safe development logging of failing schema paths/types, never values.
  • Audit other CLI routes that reuse optional-rich renderer/domain schemas.

Acceptance criteria

  • model list succeeds when optional model fields are explicitly undefined.
  • model config-get succeeds with sparse effective configuration.
  • Returned output passes both the canonical route schema and JsonValueSchema.
  • No provider secrets, raw auth state, or unknown internal fields are added to the DTO.
  • Tests cover undefined optional fields, empty model lists, custom models, and multiple providers.
  • A generic route-boundary test detects non-JSON values before release.

User benefit

Model administration and diagnostics work reliably from scripts, with a stable and safely redacted JSON contract.

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions