openclaw - ✅(Solved) Fix Bug: Memory search broken on Node.js 24 — sqlite-vec unavailable & database is not open [1 pull requests, 1 comments, 2 participants]

openclaw2026-05-05 09:35:36

ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

GitHub issue URL

Helpful · Quick feedback

GitHub stats

openclaw/openclaw#77781•Fetched 2026-05-06 06:21:33

View on GitHub

Comments

Participants

Timeline

Reactions

Author

WeaveCode-UK

Participants

clawsweeper[bot]

WeaveCode-UK

Timeline (top)

commented ×1cross-referenced ×1

Error Message

"error": "database is not open"

Problem 2: `database is not open` error

The MemoryIndexManager cached instance appears to reference a closed database connection, likely caused by the initialization failure cascade from Problem 1. The error is ERR_INVALID_STATE from Node.js SQLite when operating on a closed DB. 4. Observe "database is not open" error

Root Cause

Root Cause Analysis

Fix Action

Workaround

None found. Deleting the memory database and restarting does not resolve the issue. Downgrading Node.js to v22 should work around it, but this is not ideal.

PR fix notes

PR #77999: fix(memory): reopen closed sqlite handles

Repository: openclaw/openclaw
Author: dmbyte
State: open | merged: False
Link: https://github.com/openclaw/openclaw/pull/77999

Description (problem / solution / changelog)

Summary

Detect when a cached memory index manager holds a closed sqlite handle and reopen it before search/status/sync.
Drop closed cached managers before reuse.
Add a regression test that closes the underlying DB handle and verifies status/search recover.

Why

OpenClaw could return memory_search errors like database is not open after session compaction or concurrent memory-manager lifecycle activity, even though the underlying memory database was valid.

AI assistance

This PR was prepared with Codex assistance. The human operator remains the contributor of record, reviewed the scope, and supplied and verified the live DGX Spark behavior proof before submission.

Real behavior proof

Behavior or issue addressed: memory_search could fail after compaction or memory-manager lifecycle reuse with database is not open when a cached sqlite-backed memory manager held a closed DB handle.
Real environment tested: Live DGX Spark OpenClaw sandbox, OpenShell namespace openshell, pod jarvis, container nemoclaw-web, HOME=/sandbox, Ollama embeddings using nomic-embed-text, sqlite-vec arm64 extension loaded.
Exact steps or command run after this patch:
1. Applied the runtime-equivalent patch to the live OpenClaw install.
2. Ran HOME=/sandbox openclaw memory status --json --deep.
3. Ran HOME=/sandbox openclaw memory search --query "MacBook Spark vLLM provider" --max-results 2 --json.
Evidence after fix (copied live output):

$ HOME=/sandbox openclaw memory status --json --deep
provider: ollama
model: nomic-embed-text
embeddingProbe.ok: true
vector.semanticAvailable: true
vector.available: true
vector.dims: 768
custom.searchMode: hybrid
sourceCounts: memory=1 file / 1 chunk, sessions=16 files / 81 chunks

$ HOME=/sandbox openclaw memory search --query "MacBook Spark vLLM provider" --max-results 2 --json
results[0].path: sessions/main/439ebf9c-cfa9-4679-a157-0a638ea67657.jsonl
results[0].source: sessions
results[0].score: 0.6482941466349545
results[0].vectorScore: 0.5475357472896576
results[0].textScore: 0.8833970784406473

Observed result after fix: Both live commands completed successfully. The status probe reported semantic vector memory available with embeddings ok, and search returned session-backed results. No database is not open error was returned.
What was not tested: Full repository test suite execution in the fresh clone, because dependencies were not installed there. The source change was patch checked and the live memory status/search behavior was verified on the Spark instance.
Before evidence (optional but encouraged):

Assistant: MEMORY_ERROR database is not open

Validation

git diff --check
Live DGX Spark OpenClaw memory status and search probes above

Focused Vitest was not run in the fresh clone because dependencies were not installed.

Changed files

extensions/memory-core/src/memory/index.test.ts (modified, +15/-0)
extensions/memory-core/src/memory/manager.ts (modified, +39/-0)
src/config/schema.base.generated.ts (modified, +1/-1)

Code Example

{
  "results": [],
  "disabled": true,
  "unavailable": true,
  "error": "database is not open"
}

---

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

---

Cannot enable extension loading because it was disabled at database creation.

---

params.db.enableLoadExtension(true);  // Fails if DB not created with allowExtension

---

const { DatabaseSync } = require('node:sqlite');
const db = new DatabaseSync(':memory:');  // No allowExtension
db.enableLoadExtension(true);  // ERR_INVALID_STATE on Node 24

---

const db = new DatabaseSync(':memory:', { allowExtension: true });
db.enableLoadExtension(true);  // OK

RAW_BUFFERClick to expand / collapse

Environment

OpenClaw version: 2026.5.4
Node.js version: v24.6.0
OS: macOS 26.4.1 (arm64)
Memory plugin: memory-core (bundled)

Symptoms

memory_search always returns:

{
  "results": [],
  "disabled": true,
  "unavailable": true,
  "error": "database is not open"
}

Gateway log shows on every startup:

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

Vector search (semantic) is completely non-functional.

Root Cause Analysis

Problem 1: `enableLoadExtension` fails on Node 24

Node.js 24 node:sqlite module changed DatabaseSync behavior: enableLoadExtension(true) can only work if the database was created with allowExtension: true in the constructor options. Otherwise it throws:

Cannot enable extension loading because it was disabled at database creation.

Current code (in engine-storage-Dcaew9rn.js, loadSqliteVecExtension):

params.db.enableLoadExtension(true);  // Fails if DB not created with allowExtension

Test confirming the issue:

const { DatabaseSync } = require('node:sqlite');
const db = new DatabaseSync(':memory:');  // No allowExtension
db.enableLoadExtension(true);  // ERR_INVALID_STATE on Node 24

However, the same DB works fine when opened with allowExtension: true:

const db = new DatabaseSync(':memory:', { allowExtension: true });
db.enableLoadExtension(true);  // OK

Problem 2: `database is not open` error

Impact

memory_search tool is completely unusable
memory_get is also affected
Vector/semantic recall is degraded to FTS-only (if available)
All memory indexing operations fail silently for vector embeddings

Proposed Fix

The openMemoryDatabaseAtPath function in manager-CYeCmxMa.js already passes allowExtension based on settings.store.vector.enabled, but the memory-host-sdk (engine-storage-Dcaew9rn.js) independently calls enableLoadExtension(true) on a DB reference that may not have been created with allowExtension: true.

Suggested approach:

Ensure all database connections used with sqlite-vec are opened with allowExtension: true
Remove the redundant enableLoadExtension(true) call in loadSqliteVecExtension if the DB is guaranteed to be created with allowExtension
Add Node.js 24 to the test matrix for memory operations

Steps to Reproduce

Install OpenClaw 2026.5.4 on Node.js 24.6.0
Start gateway
Call memory_search with any query
Observe "database is not open" error
Check logs for sqlite-vec unavailable warning

Workaround

None found. Deleting the memory database and restarting does not resolve the issue. Downgrading Node.js to v22 should work around it, but this is not ideal.

extent analysis

TL;DR

Ensure all database connections used with sqlite-vec are opened with allowExtension: true to resolve the database is not open error and vector search functionality.

Guidance

Review the openMemoryDatabaseAtPath function in manager-CYeCmxMa.js to confirm it passes allowExtension: true based on settings.store.vector.enabled.
Remove the redundant enableLoadExtension(true) call in loadSqliteVecExtension if the DB is guaranteed to be created with allowExtension: true.
Add a check to ensure the database connection is open before attempting to use it, to prevent ERR_INVALID_STATE errors.
Consider adding Node.js 24 to the test matrix for memory operations to catch similar issues in the future.

Example

const db = new DatabaseSync(':memory:', { allowExtension: true });
// Only call enableLoadExtension if necessary and the DB is open
if (db.isOpen()) {
  db.enableLoadExtension(true);
}

Notes

The issue seems to be specific to Node.js 24 and the node:sqlite module's changed behavior. Ensuring allowExtension: true is used when creating database connections should resolve the issue. However, thorough testing is necessary to confirm the fix.

Recommendation

Apply the suggested approach of ensuring all database connections are opened with allowExtension: true and removing the redundant enableLoadExtension(true) call, as this directly addresses the identified root cause and should restore vector search functionality.

Vote matrix · Quick signals

Works

Did the solution work? Tap to confirm.

Easy Fix

Was it a quick fix?

Time Saver

Did it save you time?

Blocking

Was it severely blocking?

Common Issue

Are others likely hitting this too?

Flaky / Intermittent

Is it intermittent?

Verified / Reproducible

Can you reproduce it reliably?

#database connection #vector store #embedding generation #cache error #pipeline error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

openclaw - ✅(Solved) Fix Bug: Memory search broken on Node.js 24 — sqlite-vec unavailable & database is not open [1 pull requests, 1 comments, 2 participants]

Recommended Tools

GitHub issue graph ai analysis

Error Message

Problem 2: database is not open error

Root Cause

Root Cause Analysis

Fix Action

Workaround

PR fix notes

PR #77999: fix(memory): reopen closed sqlite handles

Description (problem / solution / changelog)

Summary

Why

AI assistance

Real behavior proof

Validation

Changed files

Code Example

Environment

Symptoms

Root Cause Analysis

Problem 1: enableLoadExtension fails on Node 24

Problem 2: database is not open error

Impact

Proposed Fix

Steps to Reproduce

Workaround

extent analysis

TL;DR

Guidance

Example

Notes

Recommendation

Still need to ship something?

RELATED_DISCOVERY

TRENDING

Problem 2: `database is not open` error

Problem 1: `enableLoadExtension` fails on Node 24

Problem 2: `database is not open` error