BLOCKING: recipe corpus not seeded in cloud per-user DBs — all recipe features return 0 results #102

New issue

Closed

opened 2026-04-18 09:11:56 -07:00 by pyr0ball · 0 comments

pyr0ball commented

2026-04-18 09:11:56 -07:00

Owner

Summary

Every cloud user (anonymous guests and authenticated users) gets an empty per-user SQLite DB. The recipe corpus (3.1M recipes) only exists in the local dev DB and is never seeded into cloud user DBs. All recipe suggest and recipe browse endpoints return 0 results for real visitors.

Steps to reproduce

Visit https://menagerie.circuitforge.tech/kiwi as an anonymous user
Go to Recipes tab → Find → click Suggest Recipes
Go to Recipes tab → Browse → select any domain/category
Both return 0 results for any input

Expected

Recipe suggestions and recipe browser show results from the 3.1M recipe corpus.

Actual

POST /api/v1/recipes/suggest returns {"suggestions": [], ...} regardless of pantry items
GET /api/v1/recipes/browse/cuisine returns all categories with recipe_count: 0
GET /api/v1/recipes/browse/cuisine/Italian returns {"recipes": [], "total": 0}

Root cause

In CLOUD_MODE, each user gets a per-user SQLite DB at CLOUD_DATA_ROOT/{user_id}/kiwi.db. Migrations run at startup create the recipes, recipes_fts, and recipe_browser_fts tables, but they are empty because no corpus import pipeline is run for per-user DBs.

The recipe corpus (populated by scripts/pipeline/) only exists in the dev machine DB at data/kiwi.db, which is NOT volume-mounted into the cloud container.

Impact

High — the primary value proposition (recipe suggestions) is completely non-functional for all cloud users.

Options to fix

Shared read-only corpus DB (recommended): Add a separate RECIPES_DB_PATH env var pointing to a shared corpus SQLite. The recipe engine and browser search against this shared DB, while inventory/settings stay per-user. Requires query routing split in Store or a separate CorpusStore.
Corpus volume mount: Mount the populated data/kiwi.db into the cloud container at a read-only path and use ATTACH or a separate connection for recipe queries.
Seed on first user creation: Run corpus import when a new user DB is provisioned (very slow, ~30s per new user).

Option 1 is the cleanest architectural fix.

## Summary Every cloud user (anonymous guests and authenticated users) gets an empty per-user SQLite DB. The recipe corpus (3.1M recipes) only exists in the local dev DB and is never seeded into cloud user DBs. All recipe suggest and recipe browse endpoints return 0 results for real visitors. ## Steps to reproduce 1. Visit https://menagerie.circuitforge.tech/kiwi as an anonymous user 2. Go to Recipes tab → Find → click Suggest Recipes 3. Go to Recipes tab → Browse → select any domain/category 4. Both return 0 results for any input ## Expected Recipe suggestions and recipe browser show results from the 3.1M recipe corpus. ## Actual - `POST /api/v1/recipes/suggest` returns `{"suggestions": [], ...}` regardless of pantry items - `GET /api/v1/recipes/browse/cuisine` returns all categories with `recipe_count: 0` - `GET /api/v1/recipes/browse/cuisine/Italian` returns `{"recipes": [], "total": 0}` ## Root cause In CLOUD_MODE, each user gets a per-user SQLite DB at `CLOUD_DATA_ROOT/{user_id}/kiwi.db`. Migrations run at startup create the `recipes`, `recipes_fts`, and `recipe_browser_fts` tables, but they are empty because no corpus import pipeline is run for per-user DBs. The recipe corpus (populated by `scripts/pipeline/`) only exists in the dev machine DB at `data/kiwi.db`, which is NOT volume-mounted into the cloud container. ## Impact High — the primary value proposition (recipe suggestions) is completely non-functional for all cloud users. ## Options to fix 1. **Shared read-only corpus DB** (recommended): Add a separate `RECIPES_DB_PATH` env var pointing to a shared corpus SQLite. The recipe engine and browser search against this shared DB, while inventory/settings stay per-user. Requires query routing split in Store or a separate CorpusStore. 2. **Corpus volume mount**: Mount the populated `data/kiwi.db` into the cloud container at a read-only path and use ATTACH or a separate connection for recipe queries. 3. **Seed on first user creation**: Run corpus import when a new user DB is provisioned (very slow, ~30s per new user). Option 1 is the cleanest architectural fix.