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
User benefit
Model administration and diagnostics work reliably from scripts, with a stable and safely redacted JSON contract.
Summary
The current
devbuild returnsinternal_error: Route returned an invalid resultformodel listandmodel 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:
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:
modelsListRuntimeRouteinsrc/shared/contracts/routes/models.routes.tscontains model objects with many optional fields.src/main/provider/routes.tsreturnsproviderRuntime.getModelList()through that schema.PublicModelConfigSchemaalso contains optional configuration fields.CliServer.parseRouteOutput()insrc/main/cli/server.tsfirst parses the route output and then parses the result withJsonValueSchema.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.mdrequires canonical typed routes, deterministic JSON/JSONL, and stable machine-mode envelopes.Impact
Proposed direction
undefinedproperty before public route output.Acceptance criteria
model listsucceeds when optional model fields are explicitly undefined.model config-getsucceeds with sparse effective configuration.JsonValueSchema.User benefit
Model administration and diagnostics work reliably from scripts, with a stable and safely redacted JSON contract.