[bug] llm-deepseek Config namespace silently reverts to DEFAULT_MODELS (and every other field default) when one required sibling field (thinking/reasoningEffort) is missing

[FabioLeitao]

llm-deepseek's Config schema (dsh-llm-deepseek@0.1.2-rc.1) has three fields with no .default():

const Config = z.object({
  apiKeyEnv: z.string().role("credential-ref").default(DEFAULT_API_KEY_ENV),
  baseURL: z.string(),
  thinking: z.union(["enabled", "disabled"]),
  reasoningEffort: z.union(["off", "low", "high", "max"]),
  ...
  models: z.array(catalogModel).default(DEFAULT_MODELS),
  ...
});

baseURL, thinking, and reasoningEffort are required with no default. Our settings.yaml had baseURL under llm-deepseek: (needed for a local Ollama endpoint) but never had thinking:, and had reasoningEffort misplaced one level up under agent-default-model: instead of inside llm-deepseek:.

Observed symptom: every field in the llm-deepseek section silently fell back to its own .default() — including models, which fell back to the vendor's hardcoded DEFAULT_MODELS array (three cloud DeepSeek models) instead of the ~17-model local Ollama catalog we had configured. baseURL "worked" anyway only by coincidence, because we also export $DEEPSEEK_BASE_URL and that env var is honored as a separate fallback. Nothing in the terminal output, the browser, or the session log indicated the section had been rejected — we only found it by diffing dsh-llm-deepseek/lib/index.js's hardcoded array against the model picker's actual contents and reading the Zod schema by hand. A same-day-earlier code comment we found in the same file (about streamIdleTimeoutMs) shows someone had hit the identical config === void 0 symptom before and patched around it by changing that one field's factory default, without isolating that the real cause was the whole section failing as one object.

What we tried, and a loose end: adding thinking: enabled and reasoningEffort: high directly under llm-deepseek: did not fix it for us — after the change and a full dsh web restart, the catalog still fell back to DEFAULT_MODELS (confirmed by watching it change to the three stock cloud models, then reverting our patch on the array to check, then restoring). We didn't get time tonight to determine whether that's a 4th missing/mistyped field, or whether an invalid section's "last known good value" (per dsh-settings' publish/degrade behavior, mentioned in #2852) gets cached somewhere and stays stuck even after the YAML is corrected. If anyone recognizes which it is, we'd like to know — happy to test further either way.

Ask: could this namespace either get real defaults for thinking/reasoningEffort (matching whatever dsh assumes when talking to a non-DeepSeek-official endpoint), or — more generally — could a namespace validation failure surface somewhere visible (terminal log, a Settings-page banner, anything) instead of silently reverting the whole section to its schema defaults? A cordis-config namespace that's void 0 because of one missing required sibling field is very easy to mistake for "this key doesn't exist at all," which cost us a few hours before we found it by reading the vendor source directly.

Repro: point llm-deepseek.baseURL at a local Ollama endpoint, add a models: catalog under the same llm-deepseek: key, omit thinking:, boot dsh web, open the model picker.

[argszero]

I can confirm the source and, importantly, separate two distinct failure surfaces in @deepseek-ai/dsh-llm-deepseek that your report actually straddles.

The schema. packages/llm/llm-deepseek/src/index.ts:177-184:

export const Config: z<Config> = z.object({
  ...
  baseURL: z.string(),                                   // required, no default
  thinking: z.union(['enabled', 'disabled']),             // required, no default
  reasoningEffort: z.union(['off', 'low', 'high', 'max']),// required, no default
  ...
  models: z.array(catalogModel).default(DEFAULT_MODELS),  // has a default
  ...
});

baseURL, thinking, and reasoningEffort are required with no .default(). So a section missing any one of them fails Zod validation for the whole object.

Failure surface (a) — your symptom: the silent revert. When the section fails schema validation, the namespace resolves to void 0 and the settings layer quietly falls back to the schema's per-field defaults. models in particular collapses to DEFAULT_MODELS (the three cloud models). This is exactly the "whole section reverts to defaults, no signal anywhere" behavior you saw. This path never reaches apply()'s resilience branch because it fails before the config object exists.

Failure surface (b) — the "last good config" path. apply() at index.ts:413-427:

} catch (error) {
  if (lastGood === undefined) throw error
  lastRaw = raw
  ctx.logger.error('llm-deepseek: keeping the last good configuration after an invalid settings section')
  ctx.logger.error(error)
  return lastGood
}

This branch only handles a live settings snapshot that passes the schema but violates a beyond-schema bound (e.g. reasoningEffort with thinking: disabled, maxTokens ≤ 0). Crucially this one does log. Your bug is not this branch — which is why you saw nothing in the log.

Why adding thinking/reasoningEffort didn't fix it. Two candidate explanations, both worth testing:

1. There's an additional missing/typo'd required sibling in your models: catalog block. The schema runs catalogModel.parse per entry at index.ts:218-261; a bad entry (e.g. an imageDetail field, now rejected per :218; empty id; non-positive contextWindow/maxTokens; a duplicate id via :261) will also fail the whole section. Note the comment at :218: "catalog model imageDetail is no longer supported; use imagePixelBudget" — if your local catalog carries imageDetail, that's a clean reproduction trigger.
2. The Agent write/edit tools bypass settings.yaml schema validation — malformed configs crash DSH on restart #2852 "last known good value" degrade behavior may be caching the bad section in the persisted settings file, so even after you correct the YAML, a running dsh web (or a reload that reads the cache) keeps serving the degraded snapshot. This matches the earlier streamIdleTimeoutMs patch-around comment you found — someone fought the symptom (one field's factory default) without isolating that the whole section had gone void 0.

Your ask is right and is the real fix. A cordis-config namespace silently collapsing to schema defaults on a single missing required sibling is a validation-surface gap, not an adapter bug. The highest-value change is to surface a namespace-validation failure visibly: emit a warning in installSection/the settings layer (or a banner in the Settings page) when a section fails schema parse and falls back to defaults, naming the exact missing/invalid field(s). That would have saved the hours you spent diffing lib/index.js by hand.

Confirmed: this is the same "section is void 0" shape as the streamIdleTimeoutMs comment — one field's default only hides it for that one field. Happy to help trace your exact models: block if you paste it.