openclaw - 💡(How to fix) Fix [Bug]: `chunks_vec not updated — sqlite-vec unavailable` recurs every minute in 2026.5.7 despite extension being loadable manually inside the container

Filing target: openclaw/openclaw — https://github.com/openclaw/openclaw/issues/new Likely related (CLOSED): #74823, #75624, #82597, #77781, #77838, #65033 Likely related (OPEN): #65156 (SQLite ABI mismatch), #66977 (Node node:sqlite OMIT_LOAD_EXTENSION), #62599 (false vector state) OD-side ref: reviews/audits/PILOT-COMPANION-DM-AUDIT-2026-05-17.md lines 23 + 164 (open 9 days)

TL;DR

On alpine/openclaw:2026.5.7 (which is actually Debian bookworm-slim + Node 24.14.0, despite the publisher namespace), the active-memory extension emits [memory] chunks_vec not updated — sqlite-vec unavailable. Vector recall degraded. every ~60s. The [email protected] npm package and its vec0.so binding are both present inside the container, and a manual sqliteVec.load(db) call from a Node REPL inside the same container succeeds (vec_version → "v0.1.9"). The plugin-context call to loadSqliteVecExtension nonetheless fails — and the underlying error string is suppressed so we cannot tell whether this is an ABI mismatch, an enableLoadExtension permission strip in the plugin SDK, a worker-thread cwd resolution problem, or (per #75624) a misleading warning that actually means "no embedding provider, dimensions undefined".

Primary ask: even if no fix lands, please surface the underlying loadError string at INFO on first failure. Right now the diagnostic is fully blind.

Environment

Symptom

The gateway logs this warning approximately every minute:

[memory] chunks_vec not updated — sqlite-vec unavailable. Vector recall degraded.

It fires on every memory chunk write, which means semantic recall is completely offline for the active-memory plugin even though all the on-disk artifacts the loader needs are in place. We've been running with degraded vector recall for 9 days.

What we verified works (inside the running container)

Running as node user in the live container (not a fresh shell):

1. npm package is on disk:

   /app/node_modules/sqlite-vec/package.json  → version 0.1.9

2. Platform binding is on disk:

   /app/node_modules/sqlite-vec-linux-x64/vec0.so  (present, readable)

3. ldd vec0.so shows only the usual libc / ld-linux / vdso dependencies — no missing libraries.

4. Manual load via the public sqlite-vec API works:

   const Database = require('better-sqlite3');
   const sqliteVec = require('sqlite-vec');
   const db = new Database(':memory:');
   sqliteVec.load(db);
   console.log(db.prepare('SELECT vec_version() AS v').get());
   // → { v: 'v0.1.9' }

   Both enableLoadExtension(true) is implicit and loadExtension() succeeds, and vec_version() is registered.

What fails

The plugin-context invocation of loadSqliteVecExtension inside the memory-core / active-memory extension fails — and the failure path drops to vectorReady = false, which triggers the recurring degraded-write warning.

Relevant dist-compiled files inside the container:

• /app/dist/engine-storage-BTGiRLcC.js:91-115 — loadSqliteVecExtension (the hashed filename in 2026.5.7; equivalent to the engine-storage-CGGr65kV.js / engine-storage-CO3qFXo7.js referenced in #74823 / #75624)
• /app/extensions/memory-core/src/memory/manager-sync-ops.ts:230-280 — fail-soft to vectorReady = false
• /app/extensions/memory-core/src/memory/manager-vector-warning.ts — the recurring warning emitter

Hypotheses (ordered by likelihood)

Aware that #74823 was closed and #75624 reframed the symptom — flagging where each hypothesis lines up with prior issues.

1. Worker-thread / cwd resolves the binding path away from /app

sqliteVec.getLoadablePath() resolves the binding .so location relative to the sqlite-vec package's own location, which is fine in the main thread (cwd /app) but may resolve to an unwritable / nonexistent path inside the plugin worker thread if the plugin SDK rebinds __dirname or process.cwd. The hashed bundle filename changes across releases (CGGr65kV → CO3qFXo7 → BTGiRLcC), which is consistent with this code being actively reshuffled and the path-resolution edges shifting underneath. This is the same surface as #74823 (closed without clear root cause).

2. enableLoadExtension(true) is being stripped by the plugin SDK sandbox before the plugin's db instance reaches loadExtension

The closed Node-24 issue #65033 documented that DatabaseSync requires { allowExtension: true } at construction. If the plugin-SDK path for better-sqlite3 follows a similar sandbox policy and drops enableLoadExtension(true) before the plugin gets the db handle, the load will fail with a permission-class error that the current emitter swallows. Hypothesis 1 from #66977 is the macOS / node:sqlite analogue.

3. SQLite ABI mismatch between [email protected] and [email protected]'s prebuilt vec0.so

Per the open #65156: sqlite-vec 0.1.9's linux-x64 binary was compiled against SQLite ~3.45.x, but [email protected] may bind a newer SQLite that the extension function-registration ABI doesn't match — the extension would "load" but register no functions, causing the downstream "no such function: vec_version" / vectorReady = false collapse. If true, this needs a sqlite-vec rebuild upstream, but openclaw is best positioned to detect and surface it.

4. (Per #75624) The warning is misleading — sqlite-vec actually loaded, but dimensions is undefined because no embedding provider is configured

If we don't have an embedding provider wired into the active-memory plugin's runtime config, ensureVectorReady never sets dimensions, vectorReady stays false, and the warning fires even though loadError is null. This was the #75624 root cause. We are running with a Claude Code runtime and no separate OpenAI key — so this is genuinely possible and would mean the bug is mis-attribution, not a load failure. This is the cheapest hypothesis to falsify with the diagnostic ask below.

Minimal reproduction

docker run --rm -it \
  --entrypoint bash \
  alpine/openclaw:2026.5.7 \
  -lc "node -e \"
    const Database = require('/app/node_modules/better-sqlite3');
    const sqliteVec = require('/app/node_modules/sqlite-vec');
    const db = new Database(':memory:');
    sqliteVec.load(db);
    console.log(db.prepare('SELECT vec_version() AS v').get());
  \""

Expected (the "good" case): { v: 'v0.1.9' }. Reproduces the bug: run any active-memory-enabled agent for >1 minute and watch the gateway log — chunks_vec not updated — sqlite-vec unavailable. Vector recall degraded. fires regardless of which combination of OpenClaw runtime / embedding provider is wired in.

Suggested fix or instrumentation (in priority order)

1. Surface the suppressed loadError at INFO on first failure. Currently logMemoryVectorDegradedWrite (per #75624 trace at manager-jzSMQjEt.js:1843) emits a generic warning even when loadError is null. At minimum, when loadError is non-null, include : ${loadError} in the warning (this code path already exists per #75624's quote). When loadError IS null but vectorReady is false, log a distinct message that names the actual blocker — dimensions undefined (no embedding provider configured) vs extension loaded but registered no functions (ABI mismatch suspected) vs enableLoadExtension denied. The three classes are diagnosable from inside loadSqliteVecExtension's try-block already; only the surfacing is missing.

2. Probe and emit a one-line diagnostic on plugin init showing: vectorEnabled, loadError, extensionPath used, vec_version() returned, dimensions. One line, once per process — gives downstream operators the four facts they need without grepping dist bundles.

3. (If hypothesis 3 / ABI mismatch holds) pin sqlite-vec to a version known-good against the SQLite shipped with better-sqlite3@^12.10, or document the supported matrix.

Workaround we're considering

None viable from our side — engine-storage-*.js is dist-compiled into the vendored image and patching it locally would be lost on every image rebuild. The active-memory extension's runtime is opaque to us. We're filing upstream rather than working around.

Cross-references

• Open prior occurrences in our codebase:
  • reviews/audits/PILOT-COMPANION-DM-AUDIT-2026-05-17.md:23 — original observation 2026-05-17
  • reviews/audits/PILOT-COMPANION-DM-AUDIT-2026-05-17.md:164 — listed as 15-min "side fix" (still open 9 days later)
• Closed prior openclaw issues that look like duplicates of subsets of this bug: #74823, #75624, #82597, #77781, #77838, #65033
• Open openclaw issues with overlapping mechanisms: #65156 (ABI mismatch), #66977 (load-extension permission), #62599 (false vector state reporting)

The fact that this symptom has been opened-and-closed at least 5 times in 6 weeks across overlapping-but-not-identical root causes is itself a signal: the current emitter conflates ≥4 distinct failure modes under one warning string. Whichever specific fix lands, please consider splitting the warning by class so the next operator who hits this can self-diagnose from the log alone.

Drafted from OrgDesign-side investigation 2026-05-26. Live-container diagnostics were performed via sub-agent A3 earlier in the session against a production-soak container (+966559081004 WhatsApp gateway) and reproduce cleanly against a fresh docker run of the same image tag.