v0.1.6-rc1: search/ask broken — embedder JSON-RPC params mismatch #129

New issue

Open

opened 2026-05-20 14:21:47 +00:00 by zaelgohary · 0 comments

zaelgohary commented

2026-05-20 14:21:47 +00:00

Member

Symptom

Fresh deploy of hero_books 0.1.6-rc1 + any published hero_embedder (0.1.2 / 0.1.3 / 0.2.0-rc1 / dev). Import works, books appear in the library, but the embedder upload step always fails:

Warning: could not ensure namespace 'default': Vector store error: Failed to create namespace: RPC error -32602: Invalid params: invalid type: map, expected a sequence
hero_os_guide: indexing error: Vector store error: Batch add failed: RPC error -32602: Invalid params: invalid type: map, expected a sequence
Total: 0 documents uploaded to namespace 'default'

With no vectors uploaded, Ask the Librarian returns No results found ... for every query.

Root cause

hero_books_lib::vectorsdk sends JSON-RPC params: { ... } (map). Every published hero_embedder binary (incl. dev) parses params as a positional sequence and rejects map params with -32602. The two halves shipped from incompatible schema generations.

Secondary bug — `check_embedder_warning` ignores HTTP URLs

crates/hero_books_server/src/web/server.rs:3943 only honours unix:// URLs; any HTTP HERO_EMBEDDER_URL falls through to default_embedder_socket_path() and fails the existence check, so the misleading banner Search unavailable: embedder service not running. Start it with 'make embedder' or install hero_embedder. fires even when the embedder is actually reachable over HTTP.

Tertiary bug — `VectorStore::connect` ignores HTTP URLs

crates/hero_books_lib/src/vectorsdk/store.rs:165 does config.embedder_url.replace("unix://", "") then HeroEmbedderClient::connect_socket(&socket_path) — so an http://... URL gets opened as a Unix socket path → os error 2 (ENOENT). The SDK does expose connect_http; the books client should branch on the URL scheme.

Repro

Deployed on books.gent01.dev.grid.tf (TFGrid VM, hero_proc 0.4.4, embedder running on 127.0.0.1:3380). With HERO_EMBEDDER_URL=http://127.0.0.1:3380/ set in hero_books_server's env, import via UI shows the warnings above; switching to unix:///.../hero_embedder/rpc.sock (with socat bridging to the HTTP port) gets past the connection step but hits the map-vs-sequence error against every published embedder version.

Expected

A released hero_books should pair with a released hero_embedder (or hero_memory) where import-then-search completes end-to-end without manual binary surgery.

Suggested fix

Either:

Publish a hero_embedder build that matches the map-params schema 0.1.6-rc1 sends, or
Ship 0.1.6-final on top of the development_hero_memory cutover that routes through hero_memory instead (and publish the full hero_memory_inference / _server / _ui binaries — currently only the CLI is in the latest release).

Also worth fixing in 0.1.6: the HTTP-URL handling in check_embedder_warning and VectorStore::connect (above) — those are independent of the embedder version and would make HTTP deployments usable.

## Symptom Fresh deploy of `hero_books 0.1.6-rc1` + any published `hero_embedder` (0.1.2 / 0.1.3 / 0.2.0-rc1 / dev). Import works, books appear in the library, but the embedder upload step always fails: ``` Warning: could not ensure namespace 'default': Vector store error: Failed to create namespace: RPC error -32602: Invalid params: invalid type: map, expected a sequence hero_os_guide: indexing error: Vector store error: Batch add failed: RPC error -32602: Invalid params: invalid type: map, expected a sequence Total: 0 documents uploaded to namespace 'default' ``` With no vectors uploaded, `Ask the Librarian` returns `No results found ...` for every query. ## Root cause `hero_books_lib::vectorsdk` sends JSON-RPC `params: { ... }` (map). Every published `hero_embedder` binary (incl. `dev`) parses `params` as a positional sequence and rejects map params with `-32602`. The two halves shipped from incompatible schema generations. ## Secondary bug — `check_embedder_warning` ignores HTTP URLs [crates/hero_books_server/src/web/server.rs:3943](https://forge.ourworld.tf/lhumina_code/hero_books/src/tag/v0.1.6-rc1/crates/hero_books_server/src/web/server.rs#L3943) only honours `unix://` URLs; any HTTP `HERO_EMBEDDER_URL` falls through to `default_embedder_socket_path()` and fails the existence check, so the misleading banner `Search unavailable: embedder service not running. Start it with 'make embedder' or install hero_embedder.` fires even when the embedder is actually reachable over HTTP. ## Tertiary bug — `VectorStore::connect` ignores HTTP URLs [crates/hero_books_lib/src/vectorsdk/store.rs:165](https://forge.ourworld.tf/lhumina_code/hero_books/src/tag/v0.1.6-rc1/crates/hero_books_lib/src/vectorsdk/store.rs#L165) does `config.embedder_url.replace("unix://", "")` then `HeroEmbedderClient::connect_socket(&socket_path)` — so an `http://...` URL gets opened as a Unix socket path → `os error 2 (ENOENT)`. The SDK does expose `connect_http`; the books client should branch on the URL scheme. ## Repro Deployed on `books.gent01.dev.grid.tf` (TFGrid VM, hero_proc 0.4.4, embedder running on 127.0.0.1:3380). With `HERO_EMBEDDER_URL=http://127.0.0.1:3380/` set in `hero_books_server`'s env, import via UI shows the warnings above; switching to `unix:///.../hero_embedder/rpc.sock` (with `socat` bridging to the HTTP port) gets past the connection step but hits the map-vs-sequence error against every published embedder version. ## Expected A released `hero_books` should pair with a released `hero_embedder` (or `hero_memory`) where import-then-search completes end-to-end without manual binary surgery. ## Suggested fix Either: 1. Publish a `hero_embedder` build that matches the map-params schema 0.1.6-rc1 sends, or 2. Ship 0.1.6-final on top of the `development_hero_memory` cutover that routes through `hero_memory` instead (and publish the full `hero_memory_inference` / `_server` / `_ui` binaries — currently only the CLI is in the `latest` release). Also worth fixing in 0.1.6: the HTTP-URL handling in `check_embedder_warning` and `VectorStore::connect` (above) — those are independent of the embedder version and would make HTTP deployments usable.