openclaw - 💡(How to fix) Fix [Bug]: sqlite-vec extension fails to load silently despite vec0.so being present and functional [1 comments, 2 participants]

Description

The memory-core plugin's vector store reports sqlite-vec unavailable on every memory chunk write, even though the sqlite-vec npm package (v0.1.9) is installed and the native vec0.so extension loads successfully when called manually inside the container.

This causes two problems:

1. Silent performance degradation — every agent turn triggers synchronous chunk-writes for 30+ memory files, all of which fail the vector path and fall back. This creates an I/O storm that blocks the event loop and contributes to WebSocket latency/disconnects (code 1006).
2. No vector recall — the chunks_vec table is never populated, so semantic memory search is completely non-functional.

Environment

• OpenClaw version: 2026.4.10 (ghcr.io/openclaw/openclaw:2026.4.10)
• Node.js: v24.14.0 (bundled in image)
• Platform: Linux x86_64 (Docker on TrueNAS SCALE)
• sqlite-vec: 0.1.9 (npm), vec0.so at /app/node_modules/sqlite-vec-linux-x64/vec0.so

Reproduction

The gateway logs this warning on every memory chunk write:

[memory] chunks written for MEMORY.md without vector embeddings — chunks_vec not updated (sqlite-vec unavailable). Vector recall degraded for this file.

This repeats for every file in the memory/ directory on each agent turn.

Diagnostic Evidence

1. The extension loads fine manually

$ node --experimental-sqlite -e "
const {DatabaseSync} = require('node:sqlite');
const db = new DatabaseSync(':memory:', { allowExtension: true });
db.enableLoadExtension(true);
db.loadExtension('/app/node_modules/sqlite-vec-linux-x64/vec0.so');
console.log('SUCCESS');
"
# Output: SUCCESS

Both enableLoadExtension(true) and loadExtension() succeed. The sqlite-vec npm package's load(db) helper also works:

$ node --experimental-sqlite -e "
const {DatabaseSync} = require('node:sqlite');
const db = new DatabaseSync(':memory:', { allowExtension: true });
import('sqlite-vec').then(sv => { sv.load(db); console.log('SUCCESS'); });
"
# Output: SUCCESS

2. The .so has no dependency issues

$ ldd /app/node_modules/sqlite-vec-linux-x64/vec0.so
  linux-vdso.so.1 => ...
  libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
  /lib64/ld-linux-x86-64.so.2

3. The code path looks correct

In engine-storage-CGGr65kV.js:

// src/memory-host-sdk/host/sqlite-vec.ts
async function loadSqliteVecExtension(params) {
    const sqliteVec = await import("sqlite-vec");
    const resolvedPath = normalizeOptionalString(params.extensionPath);
    const extensionPath = resolvedPath ?? sqliteVec.getLoadablePath();
    params.db.enableLoadExtension(true);
    if (resolvedPath) params.db.loadExtension(extensionPath);
    else sqliteVec.load(params.db);
    // ...
}

In manager-D6mZh4aS.js:

function openMemoryDatabaseAtPath(dbPath, allowExtension) {
    const { DatabaseSync } = requireNodeSqlite();
    const db = new DatabaseSync(dbPath, { allowExtension });
    // ...
}

The allowExtension parameter is driven by this.settings.store.vector.enabled.

4. The plugin config schema rejects user overrides

Attempting to set store.vector.enabled via the plugin config:

"memory-core": {
  "config": {
    "store": { "vector": { "enabled": true } }
  }
}

Results in:

Config invalid — plugins.entries.memory-core.config: invalid config: must NOT have additional properties

So there is no user-facing way to influence store.vector.enabled.

Expected Behavior

If sqlite-vec is installed and the .so is loadable, the vector store should initialize successfully and populate chunks_vec on memory writes.

Actual Behavior

The vector store silently fails during loadSqliteVecExtension(), returns { ok: false }, and every subsequent memory write logs the "sqlite-vec unavailable" warning. The exact error from the catch block is not surfaced in any accessible log (not in the app log file, not in Docker stdout).

Suggested Investigation

1. The error caught in loadSqliteVecExtension's try/catch is swallowed into { ok: false, error: formatErrorMessage(err) } but the actual error string doesn't appear in logs at the default log level. Surfacing this would immediately reveal the root cause.
2. The store.vector.enabled default and resolution path may not be setting allowExtension: true on the DatabaseSync constructor, even though the code structure suggests it should.
3. There may be a timing/initialization order issue where the database is opened before the vector config is resolved.