Module bus embedder advertises non-zero dimensions while embedding to empty vectors, so recall silently returns nothing

[YellowSnnowmann]

Summary

BusEmbeddingHost::default_embedding_provider returns a provider that advertises a real embedder — name = "module-bus", the configured cloud model, and non-zero dimensions — while the host on the far side of the bus answers one empty vector per input. An embedder that reports non-zero dimensions and returns nothing is describing itself incorrectly, and every consumer that branches on dimensions() is entitled to believe it.

The visible effect is that recall silently returns nothing.

Evidence

OpenCompany runs the same facade round-trip against the same engine two ways — in-process (namespace driver) and over the bus (module driver). One passes and one does not:

the_namespace_driver_round_trips_the_facades ... ok
the_module_driver_upholds_the_contract      ... FAILED
    assertion `left == right` failed: context must be recallable through the engine
      left: 0
     right: 1

Same engine, same store a moment earlier, same absence of a real embedder. put succeeds in both. Only recall differs.

The difference is what the two embedders say about themselves:

	NoopEmbedding (in-process)	BusEmbeddingProvider (module)
name()	"none"	"module-bus"
model_id()	"none"	the configured cloud model
dimensions()	0	cloud_dimensions (non-zero)
embed()	empty vectors	empty vectors

Only the last row matches. With dims = 0 the engine skips vector search and the chunk is found; with non-zero dims it embeds the query to an empty vector, searches, and matches nothing.

The host's callback is not the problem — its provider/model/dimensions parameters are inputs it ignores, and returning empty vectors is the intended no-op. What the engine sees is the advertised identity, and that comes from default_embedding_provider.

Why it is worth fixing rather than documenting

It fails in the shape that is hardest to notice. There is no error, no warning, and no empty-store symptom — writes work, reads work, and recall returns an empty list that is indistinguishable from "nothing matched". A host embedding this module gets an engine that believes it can do semantic recall and quietly cannot.

It also breaks the property the module seam is supposed to have: the same engine, reached over the bus, answering the same sequence identically. That is exactly what OpenCompany's differential test exists to check, and it caught this.

Suggested fix

When the far side embeds to nothing, advertise that: report dims = 0 and a "none"-style name, so the engine takes the same path the in-process no-op does. Alternatively, refuse to construct a provider whose declared dimensions cannot be honoured — but silently advertising capability the bus cannot deliver is the case to remove.

Either way the fix belongs in the advertised identity, not in the callback.

Related

Found while running OpenCompany's module conformance step against the pinned artifact (opencompany#1550). That step is currently red on this, and correctly so.

[YellowSnnowmann]

Correcting this — the mechanism I described is wrong, and so is the repository.

What I got wrong

I claimed BusEmbeddingProvider advertises non-zero dimensions() while embedding to empty vectors. It does not. ModuleConfig::cloud_embedding_dimensions defaults to 0 and the host embedding this module never sets it, so the provider reports dims = 0 — the same width NoopEmbedding reports. The table in the issue above is wrong on its most important row.

The width check in BusEmbeddingProvider::embed should also have told me this: it compares every returned vector against self.dimensions unconditionally, so a non-zero-dimension provider receiving empty vectors would have failed loudly rather than returning nothing. The symptom was silent, which is evidence against my own diagnosis, and I did not weigh it.

What is actually happening

The engine's embedder factory opts out of vector search on a config value, not on the provider's identity:

// tinymemory-core/src/tree/score/embed/factory.rs
if config.embeddings_provider().map(str::trim).is_some_and(|s| s == "none") {
    return Ok(EmbedderChoice::OptOut);
}

ModuleConfig::embeddings_provider is Option<String>, defaulting to None. A host that does not set it gets an engine that looks for a real embedder, embeds the query into a zero-width vector, and matches nothing.

The in-process path never meets this because it is handed a NoopEmbedding object directly at construction, so the factory is not consulted at all. Two ways of saying "no embedder", and only one of them travels through config.

Where the fix belongs

In the host, not here. The host embedding this module has to set embeddings_provider = "none" when its EmbeddingHost answers empty vectors — which is what OpenCompany was missing (opencompany#1550, fixed there).

Worth keeping, if you want it

There is a smaller thing left, and it is the reason this took three attempts to diagnose: a module configured to embed into zero dimensions, with no embeddings_provider set, is in a state that cannot work and cannot say so. Refusing that combination at setup — or defaulting embeddings_provider to "none" when cloud_embedding_dimensions == 0 — would turn a silent empty result set into something a host can act on. Closing this otherwise, since the defect I filed does not exist.