fix(tinycortex): key embeddings on the resolved provider slug

[senamakel]

Summary

• Adopt tinycortex's required EmbeddingConfig.provider field in memory_config_from. tinymemory main does not currently compile against tinycortex main — this fixes that.
• Map it to effective_embedder_slug(config), the slug the embedder ladder actually resolves to — deliberately not config.memory().embedding_provider.
• Advance vendor/tinycortex to the merge commit carrying the field, and update Cargo.lock.
• Adds a regression test that fails on the naive mapping and passes on this one.

Problem

tinycortex added a required provider field to EmbeddingConfig in tinyhumansai/tinycortex#123 / #124. This crate never adopted it, so the struct literal in core/src/tinycortex/config.rs no longer compiles:

error[E0063]: missing field `provider` in initializer of `EmbeddingConfig`
  --> core/src/tinycortex/config.rs:42:20

This is a live incompatibility between the two main branches, not something introduced here. It has been latent because consumers pin an older tinycortex; it surfaced while bumping the gitlink in tinyhumansai/openhuman#5544, and I confirmed it reproduces on the commit before that PR's tinycortex change, so it is independent of it.

Solution

The interesting part is which value to map, because provider is not cosmetic — tinycortex documents it as "part of the signature every per-model sidecar row is keyed by, so two backends serving the same model id never share a vector space." It decides which vectors are readable as one space.

The field named memory.embedding_provider looks like the obvious source and is the wrong one. This crate's own factory.rs says so explicitly:

config.memory().embedding_provider is not authoritative for how embeddings are funded … The ladder resolves local Ollama from memory_tree.embedding_endpoint or from the unified workload_local_model("embeddings") setting, and neither path rewrites memory.embedding_provider — so a user running fully local still reads as "cloud" there.

Mapping it straight through would file a fully-local user's vectors under the cloud provider. So the mapping walks the same ladder the read and write factories walk, via the existing effective_embedder_slug, and the reasoning is recorded at the mapping site so the next person does not "simplify" it back to the config field.

Existing data is unaffected. signatures_equivalent disqualifies on a provider mismatch only when both sides declare a provider, and rows written under the legacy spelling declare none — so previously-embedded rows keep matching regardless of what this now writes.

Impact

• Restores compilation of tinymemory against current tinycortex. No API change.
• New embedding rows are keyed by the resolved backend rather than a possibly-stale config string. Legacy rows continue to match (see above), so no re-embedding and no migration.
• vendor/tinycortex advances to 0a7a067; Cargo.lock follows.

Validation

• cargo check --workspace --all-targets — clean (fails on main with the E0063 above).
• cargo check -p tinymemory-core --features memory-git --all-targets — clean.
• cargo test -p tinymemory-core tinycortex::config — 4 passed.
• cargo fmt --check — clean.
• Regression test proven red-before-green: with the mapping temporarily switched to config.memory().embedding_provider.clone(), embedding_provider_is_the_resolved_slug_not_the_config_field fails with right: "ollama"; restored, it passes. The test configures rung 1 of the ladder (explicit Ollama endpoint + model) while leaving memory.embedding_provider = "cloud", which is exactly the mis-keying scenario.
• Verified downstream in the OpenHuman host: with this branch and tinycortex 0a7a067, cargo check --no-default-features --features memory-git --lib is clean.

Related

• Fixes the skew introduced by fix(memory): unblock legacy chunk reembedding tinycortex#123 and #124.
• Unblocks chore(deps): move git2 ownership into tinycortex openhuman#5544, whose tinycortex gitlink bump cannot land until this merges.
• Commit history is the auto-commit hook's granular checkpoints; the change is the single mapping edit plus its test, described above.

[coderabbitai]

Warning

Review limit reached

@senamakel, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 60 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: dcfa8aca-cac0-4968-983d-5446abb4c608

📥 Commits

Reviewing files that changed from the base of the PR and between ed524f1 and bff74cf.

⛔ Files ignored due to path filters (1)

• Cargo.lock is excluded by !**/*.lock

📒 Files selected for processing (2)

• core/src/tinycortex/config.rs
• vendor/tinycortex

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}