Self-hosted server (linux-x64 v0.0.6): documents permanently stuck at status: "queued" — ingestion worker never starts due to Rivet WASM load failure

[Tomayachi]

Environment:

Platform: linux-x64 (Manjaro, AMD Ryzen)
supermemory-server version: 0.0.6
LLM provider: OpenAI-compatible endpoint (LM Studio, local)

Startup error:

error: Cannot find module '@rivetkit/rivetkit-wasm' from '/$bunfs/root/supermemory-server'
GET - /api/rivet/metadata failed

Repro steps:

Fresh install via curl -fsSL https://supermemory.ai/install | bash
Start server, confirm it's listening on :6767
Submit the exact example from the self-hosting quickstart docs:
bash
curl -X POST http://localhost:6767/v3/documents
-H "Authorization: Bearer sm_..."
-H "Content-Type: application/json"
-d '{"content": "supermemory is running locally!"}'
Response: {"id":"...","status":"queued"}
Poll GET /v3/documents/ repeatedly — status never advances past queued, though dreamingStatus shows "done"
/v3/search for the ingested content returns {"results":[],"total":0}
Server logs show no activity at all when a document is submitted — no dequeue attempt, no error per-job, just the one startup Rivet error and then silence

Expected: document processes to a terminal status (e.g. done/processed) and becomes searchable.

Suspected cause: the ingestion queue worker appears to depend on Rivet (@rivetkit/rivetkit-wasm), and since that module fails to load in the compiled binary at startup, the worker loop never initializes — while the HTTP API server itself stays up and accepts requests normally, masking the failure until you check document status.

[linear-code]

ENG-1188

[Tomayachi]

Update: Tried 0.0.7-rc.2 and it resolves the core issue — documents no longer get stuck permanently at queued. Wanted to close the loop with what I found, since there's a second smaller issue worth knowing about too.

Confirmed fixed in rc.2:
Documents now progress through the pipeline (queued → indexing → searchable) instead of hanging forever. Extraction and embedding both complete successfully:

[Extraction] Extracted with text
[Workflow] Document embedding 1 chunks (1 batches)
[Workflow] Document stored 1 embedded chunks

Search returns correct results with reasonable similarity scores shortly after.

New (minor) issue in rc.2:
A background step, maintain-container-description, times out after 30s when using a local OpenAI-compatible LLM (LM Studio + Qwen3 27B, non-cloud inference speed):

[workflow] maintain-container-description ✗ Step "maintain-container-description" timed out after 30000ms
ts=... level=error message="napi run handler failed" ... error="Step "maintain-container-description" timed out after 30000ms"

This doesn't block ingestion or search — the document still reaches an indexed/searchable state — but it does throw an error on every ingest and presumably leaves the container description unset. Suspect the 30s timeout is tuned for cloud-inference latency and may be too tight for local model backends. A configurable timeout (or a longer default when OPENAI_BASE_URL points somewhere non-default) would likely fix this for local-LLM users.

Setup for reference: self-hosted, linux-x64, LLM + embeddings both routed through LM Studio (Qwen3 27B chat, text-embedding-qwen3-embedding-0.6b for embeddings).

Happy to test a fix if useful — thanks for the quick turnaround on rc.2.