Repository navigation
v0.0.6 linux-x64: ingestion and search silently broken — @rivetkit/rivetkit-wasm not bundled into standalone binary #1315
Description
Summary
The server-v0.0.6 supermemory-server-linux-x64 binary ships without the @rivetkit/rivetkit-wasm module compiled in. The server boots and answers HTTP 200, but the entire rivet-backed async pipeline is dead:
- Document ingestion never runs — documents stay in
status: "queued"forever /v3/searchand/v4/searchreturn{"results":[],"total":0}for all queries, instantly (~40 ms, i.e. query embedding never executes)GET /api/rivet/metadatafails on every call
Because everything returns HTTP 200, the breakage is silent — no crash, no fatal log, just an empty memory store from the client's perspective.
error: Cannot find module '@rivetkit/rivetkit-wasm' from '/$bunfs/root/supermemory-server'
GET - /api/rivet/metadata failed
Reproduction (fresh data dir, no pre-existing state)
curl -sLO https://github.com/supermemoryai/supermemory/releases/download/server-v0.0.6/supermemory-server-linux-x64
chmod +x supermemory-server-linux-x64
mkdir /tmp/sm-fresh
SUPERMEMORY_DATA_DIR=/tmp/sm-fresh SUPERMEMORY_PORT=6768 OPENAI_API_KEY=sk-dummy \
./supermemory-server-linux-x64
# wait for "http server listening", then:
curl http://127.0.0.1:6768/api/rivet/metadataResult: the module error above is logged, the endpoint returns the Bun fallback error page, and any document POSTed via /v3/documents stays queued indefinitely.
Reproduced on Linux Mint 22.3 (Ubuntu 24.04 base), kernel 6.17, x86_64.
Binary sha256 (matches the published .sha256 asset): bb1b7cee393818236873b8e2518a435e10d9195e27ea5608a3af48a733ef8ee8
Root cause (from inspecting the binary)
The rivet runtime loaders use computed dynamic import specifiers, which Bun's bundler cannot statically analyze, so the modules are never embedded into the standalone binary:
// wasm path (decompiled from the v0.0.6 binary)
async function Pt8($){let e=($?.bindings) ?? await import(["@rivetkit","rivetkit-wasm"].join("/")); ...}
// napi path
async function pt8(){let $=await import(["@rivetkit","rivetkit-napi"].join("/")); ...}At runtime Bun resolves the specifier against /$bunfs/root/ and finds nothing → Cannot find module.
For comparison, the v0.0.5 binary bundled the napi loader statically — the per-platform stubs are visible in the binary (require("./rivetkit-napi.linux-x64-musl-….node") etc.) — which is why v0.0.5 works on the same machine.
Likely fix: replace the ["@rivetkit","rivetkit-wasm"].join("/") indirection with static import specifiers (or explicit bundler externals/assets) so Bun embeds the modules.
Notes
- This is independent of failed to apply embedded migration schema "observatory" already exists #1314 (the regenerated
0000_quiet_slydebaseline failing on existing DBs withschema "observatory" already exists). We hit that too on upgrade from v0.0.5 and worked around it by applying the schema delta manually and recording the new migration hash — after which v0.0.6 boots cleanly but is still unusable due to this bundling issue. Both bugs block the 0.0.5 → 0.0.6 upgrade path on linux-x64; this one also breaks fresh installs. - Happy to test a fixed build.
Activity
linear-code commentedon Jul 20, 2026
ENG-1093
amitray007 commentedon Jul 24, 2026
Faced the same issue, document pipeline seems to be broken. Reverting back to v0.0.5 works for the time being.
JithendraNara commentedon Jul 25, 2026
Thanks for confirming — good to know it's not an isolated setup issue. Pinning to v0.0.5 is the right workaround for now.
Root cause on v0.0.6 linux-x64: the standalone binary ships without
@rivetkit/rivetkit-wasmcompiled in, so the whole rivet-backed async pipeline silently no-ops while still returning HTTP 200 — ingestion staysqueuedforever and search returns empty instantly. The team has it tracked internally as ENG-1093 (Linear linkback above), so a fixed binary should land there.Heads-up: I've since moved to a different memory backend, so I likely won't be validating future releases — but this issue should stay valid until they re-bundle the wasm module.
oddrap commentedon Aug 8, 2026
Independent confirmation on macOS / Apple Silicon (Darwin arm64) with the official
server-v0.0.6binary.I used a fresh disposable data directory and two short synthetic text documents only.
POST /v3/documentsreturned HTTP 200 and document IDs, but both documents remainedqueuedafter 180 seconds. After a controlled restart and another 60 seconds, both were stillqueued; search did not return their canary text and deletion returned HTTP 409 because they were still processing.The server log contained the same failure:
This is therefore not confined to the Linux release artifact. I did not use a real corpus or any agent transcript. Happy to retest a fixed Darwin arm64 build.
Prathmesh010190 commentedon Oct 20, 2026
Retested the linux-x64 server binaries on GitHub Codespaces. Each run used a fresh data dir and
OPENAI_API_KEY=sk-dummy, checkingGET /api/rivet/metadataand the log forCannot find module '@rivetkit/rivetkit-wasm'.Cannot find module '@rivetkit/rivetkit-wasm' from '/$bunfs/root/supermemory-server'andGET - /api/rivet/metadata failed, and the endpoint returns the Bun fallback HTML page./api/rivet/metadatareturns valid JSON. I checked startup and the metadata endpoint only, not ingestion./api/rivet/metadatareturns valid JSON. I also ingested one short synthetic text document viaPOST /v3/documents. It returnedstatus: "queued", and about 30 seconds laterPOST /v3/searchreturned it with the expected chunk (total: 1, andupdatedAtabout 5 seconds aftercreatedAt).I did not test v0.0.7, so I can't say exactly which release first fixed it, but it appears fixed by v0.0.8 at the latest. Could someone from the team confirm that ENG-1093 shipped and close this issue?
One side note: on v0.0.9, requests without an API key returned
Unauthorized, and they worked once I sent the key printed at startup asAuthorization: Bearer .... The v0.0.6 startup log said the key is auto-applied for unauthenticated localhost requests. This is probably intentional, but anyone following the original repro steps may hit it.