[goruck]

Closes #853.

What was wrong

Setup builds one embedding client per provider type (one per server for Ollama). A second OpenAI-compatible server in the embedding chain therefore got the primary's own client. After the #751 review, the chain dropped it as a duplicate and logged nothing, so the fallback the user picked was never used. A second OpenAI or Gemini provider was dropped the same way.

Decision

We are not giving each OpenAI-compatible server its own client. Instead this enforces the rule that the #751 form and repair text already state: an embedding fallback is kept only when the primary and the fallback are both Ollama. Each Ollama server's build of the model is checked against the primary's (#855). Two OpenAI-compatible servers can serve different weights under the same model name, and nothing can check that, so failing over between them could mix models in the memory store without anyone noticing.

Changes

• split_embedding_chain leaves out every other fallback.
  • One the user chose raises the embedding_fallback_other_model repair and logs a WARNING.
  • One HGA added on its own is logged at INFO.
• The repair text now gives both reasons: a second OpenAI or Gemini provider adds no failover, and any other fallback could mix models (en, cs, zh-Hans).
• The size check (Embedding store size mismatch with non-Ollama providers, and a missing store table after setup, fail silently #760) now measures only a non-Ollama primary, using the primary's own client. I removed the fallback_embedding_dims_mismatch issue and its strings. It was added after v3.45.0-beta.4 and could no longer be raised, so no installed release has it.
• Text that still described Ollama fallbacks behind a non-Ollama primary is updated: the Ollama fallback size repair, docs/configuration.md and code comments.
• New TODOS entry: the size issue is cleared on every unload, so a primary that can't be measured at the next startup loses it. This predates this PR (Embedding store size mismatch with non-Ollama providers, and a missing store table after setup, fail silently #760).

Users who saved a same-type non-Ollama embedding fallback before #751 will now see the repair issue after upgrading. Saving the Embeddings feature clears it.

Testing

• make lint passes and make typecheck reports 0 errors. make test: 6470 passed, 1 skipped.
• New tests:
  • unit: no fallback is kept behind an OpenAI-compatible, OpenAI or Gemini primary
  • setup, chosen fallback: a same-type fallback (all three types) raises the repair with a WARNING, and the size check measures the primary only
  • setup, automatic fallback: the same case logs at INFO and raises no repair
  • the size-check tests are rewritten for the primary-only check
• The new tests fail without the resolver change.
• Not field-tested. The test box has an Ollama primary, so this code path doesn't run there.

Review

gstack /review converged after 3 cycles (2 of them made edits).

• Codex adversarial: clean in all 3 cycles.
• Claude adversarial, red team, and the testing, maintainability, security, performance and simplification specialists ran in every cycle. Every confirmed finding was fixed.
• Three low items were skipped by choice:
  • a now-dead wrapper, _embedding_instance_for_provider
  • a guard for the size check's assumption that the chain's head type equals the configured primary type, which holds today
  • an existing catch-all branch that treats an unknown embedding provider type as Ollama

Ships in the 3.45.0 bundle.

🤖 Generated with Claude Code

https://claude.ai/code/session_019kuwyteUa5Q6rkkB8hgwwj

[claude]

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.

🤖 Generated with Claude Code