[Bug] memos-local-plugin : chunks table never created — causes viewer dashboard data drift and auto-recall injection failure

[MacQimw]

[Bug] memos-local-plugin 2.0: chunks table never created — causes viewer dashboard data drift and auto-recall injection failure

Pre-submission checklist

• I have searched existing issues and this hasn't been mentioned before
• I have read the project documentation and confirmed this issue doesn't already exist
• This issue is specific to MemOS and not a general software issue

Bug Description

Summary

In memos-local-plugin v2.0.x, the chunks table is never created by any of the 12 schema migrations. This causes the MemOS Viewer dashboard (port 18799) to display data correctly for a brief moment after gateway restart, then drift to empty/zero as soon as a message is processed. Auto-recall injection also fails to retrieve relevant context.

Symptoms

1. Viewer dashboard data drift: After openclaw gateway restart, the dashboard at http://127.0.0.1:18799 shows correct data momentarily. Within 10-20 seconds — or immediately upon sending a message to the agent — all data disappears and shows empty/zero.
2. Auto-recall returns empty or irrelevant results: Cross-session memory recall fails. Manual vector search via Ollama bge-m3 works correctly (relevant results found in top-K), but the plugin's auto-recall pipeline does not inject them.
3. embedding_retry_queue fills up: 72 failed retry entries referencing a corrupted local ONNX model (separate issue, see below).

Key Finding

The chunks table — which the Viewer dashboard and retrieval pipeline depend on — does not exist in the 2.0 database. Examination of all 12 SQL migration files reveals that none of them contain a CREATE TABLE chunks statement.

This is a regression from 1.0 (memos-local-openclaw-plugin), where chunks is properly created via CREATE TABLE IF NOT EXISTS chunks in sqlite.ts.

How to Reproduce

1. Install @memtensor/memos-local-plugin v2.0.10 on OpenClaw (tested on v7.1)
2. Configure embedding provider as openai_compatible (Ollama bge-m3) in config.yaml
3. Start the gateway: openclaw gateway start
4. Open http://127.0.0.1:18799 → Dashboard shows data normally ✅
5. Send any message to the agent → Dashboard data immediately drifts to empty ❌
6. Verify: sqlite3 ~/.openclaw/memos-plugin/data/memos.db ".tables" → no chunks table

Environment

• OpenClaw: v7.1 (stable release)
• memos-local-plugin: v2.0.10 (npm latest)
• OS: macOS 15 (Darwin 24.6.0, ARM64)
• Node.js: v25.8.1
• Embedding: Ollama bge-m3 (1024-dim) via OpenAI-compatible endpoint
• LLM: GLM-5.2 via third-party provider

Investigation Details

We conducted a thorough 5-round investigation (on a clone of the production environment) to isolate the root cause:

Round 1: Database schema audit

Inspected the 2.0 database (~/.openclaw/memos-plugin/data/memos.db):

Tables that exist (9 with data):

Table	Rows
traces	64,958
episodes	35,142
sessions	1,194
skills	481
api_logs	1,454
schema_migrations	12
embedding_retry_queue	72
kv, audit_events, feedback, etc.	0

Tables that are MISSING:

Table	Impact
chunks	Dashboard cannot display memory content
embeddings	No vector data for viewer
tasks	—
skill_embeddings	—
task_embeddings	—

Round 2: Migration history

All 12 migrations execute at startup:

001-initial.sql
002-embedding-retry-queue.sql
003-embedding-retry-lease.sql
004-skill-usage.sql
005-skill-trials.sql
006-world-model-version.sql
007-namespace-visibility.sql
008-feedback-experience-metadata.sql
009-policies-fts.sql
010-trace-policy-links.sql
011-hub-sharing.sql
012-trace-turn-pagination-index.sql

None of these migrations create a chunks table. The 001-initial.sql creates 13 tables: schema_migrations, sessions, episodes, traces, policies, l2_candidate_pool, world_model, skills, feedback, decision_repairs, audit_events, api_logs, kv.

Round 3: ONNX model corruption (independent issue)

Found that the local ONNX model (Xenova/all-MiniLM-L6-v2) was corrupted (8.1 MB instead of ~22 MB, Protobuf parsing failed). We deleted and re-downloaded the correct model. After restart:

• ✅ ONNX model healthy (22 MB)
• ✅ No new entries in embedding_retry_queue
• ❌ chunks table still doesn't exist
• ❌ Dashboard drift not fixed

Conclusion: ONNX corruption and missing chunks table are two independent problems.

Round 4: Configuration analysis

Config (config.yaml) specifies:

embedding:
  provider: openai_compatible
  endpoint: http://192.168.3.7:11434/v1
  model: bge-m3

However, the plugin still attempts to load the local ONNX model first, despite openai_compatible being configured. The Ollama endpoint works perfectly (verified independently). This suggests the embedding provider selection logic may have a fallback issue.

Round 5: Code-level evidence on current main branch

We verified the latest code on main (as of 2026-07-20):

• 1.0 plugin (apps/memos-local-openclaw/src/storage/sqlite.ts): Contains CREATE TABLE IF NOT EXISTS chunks ✅
• 2.0 plugin (apps/memos-local-plugin/core/storage/migrations/001-initial.sql): Does NOT contain CREATE TABLE chunks ❌
• 2.0 plugin (server/routes/migrate.ts): Comments reference "The schema (chunks/skills/tasks) is the same across both" — indicating chunks was expected to exist in 2.0 as well

Comparison: 1.0 vs 2.0 database

Aspect	1.0 (memos-local-openclaw)	2.0 (memos-local-plugin)
chunks table	✅ Created (42K+ rows in production)	❌ Never created
embeddings table	✅ Created	❌ Missing
traces table	—	✅ 64K+ rows
Architecture	Single chunks table	Split into traces/episodes/sessions

Root Cause Analysis

The 2.0 plugin underwent an architecture change — the flat chunks table from 1.0 was split into a normalized traces → episodes → sessions hierarchy. However:

1. The Viewer dashboard and retrieval pipeline still contain code paths that query the chunks table
2. No migration creates chunks in the 2.0 schema
3. The migrate.ts route (for importing 1.0 data) explicitly references the chunks table schema in comments

This results in:

• Startup: Dashboard reads from in-memory cache or traces pre-load → appears normal
• Message received: Triggers a refresh/re-query targeting chunks → table doesn't exist → empty result → dashboard drifts to zero

Suggested Fix Direction

Option A: Add a migration to create the chunks table (if it's still needed by viewer/retrieval code paths)

Option B: Update all code paths that reference chunks to use the new traces/episodes/sessions schema instead

Additional Context

Related issues

• [memos-local-openclaw] embedLocal leaks native ONNX memory per call; old-space fills until OOM in ~15-30s #1863 (closed): ONNX memory leak — fixed for 1.0 plugin, but 2.0 has a similar issue (local ONNX attempted before configured remote provider)
• [Bug] Multi-Agent mode: cross-agent memory injection + recursive chunk duplication (65908 records in 1 week) #1383 (open): chunks table bloat (65K records in 1 week) — confirms chunks is a known problem area
• [Feature Request] Re-embed existing memories when embedding model/provider changes #1333 (closed): Re-embed existing memories when changing embedding model — related to embedding migration

Production impact

This bug makes memos 2.0 unusable in production — the viewer is non-functional and auto-recall doesn't work. We are forced to stay on 1.0 (memos-local-openclaw-plugin v1.0.10) until this is resolved.

We have detailed investigation reports (including full database dumps, schema comparisons, and step-by-step reproduction) available if the team needs them.

Willingness to Implement

• I'm willing to implement this myself
• I would like someone else to implement this

[Memtensor-AI]

🤖 AutoDev has picked up this issue and started working on it.

Task ID: 89b461afc787e095
Working branch: bugfix/autodev-144-20260720044155175
Target branch: main
Workflow: opsp (analysis → coding → testing → PR)

I will post the PR link here once done. If I need more information, I will ask in the comments.

[MacQimw]

⚠️ This issue was auto-transferred — it belongs in MemTensor/MemOS (main repo)

Apologies for the confusion. This bug is about the local plugin (@memtensor/memos-local-plugin v2.0.x), which lives in the main MemTensor/MemOS repository — not the cloud plugin in this repo.

What happened

We attempted to file this issue in MemTensor/MemOS multiple times (both via API and via the GitHub web UI), but every issue created in the main repo gets automatically transferred/redirected to this repository (MemOS-Cloud-OpenClaw-Plugin). This happened 4 times:

• MemOS #2125 → transferred here as [Bug] memos-local-plugin 2.0: chunks table never created — causes viewer dashboard data drift and auto-recall injection failure MemOS-Cloud-OpenClaw-Plugin#141 (closed by us)
• MemOS #2126/#2127 → transferred here as [Bug] memos-local-plugin 2.0: chunks table never created — causes viewer dashboard data drift and auto-recall injection failure MemOS-Cloud-OpenClaw-Plugin#142/Feat: docker settings modify #143 (closed by us)
• MemOS #2128 → transferred here as [Bug] memos-local-plugin : chunks table never created — causes viewer dashboard data drift and auto-recall injection failure #2131 (this issue)

The actual bug location

• Package: @memtensor/memos-local-plugin v2.0.x
• Source code: apps/memos-local-plugin/ in MemTensor/MemOS
• Affected migrations: apps/memos-local-plugin/core/storage/migrations/001-initial.sql
• NOT related to: @memtensor/memos-cloud-openclaw-plugin (this repo)

Request

Could the team help transfer this issue back to MemTensor/MemOS? Or let us know if there's a correct way to file local-plugin bugs without triggering the auto-transfer.

The full investigation details have been filled in above. We have spent significant effort isolating the root cause (missing chunks table in 2.0 schema migrations) and believe this is a high-quality bug report that can help the team fix a production-blocking issue.

Thank you!

[Memtensor-AI]

🤔 AutoDev task 89b461afc787e095 needs clarification to proceed:

1. Issue [Bug] memos-local-plugin : chunks table never created — causes viewer dashboard data drift and auto-recall injection failure #2131 describes a bug in @memtensor/memos-local-plugin v2.0.10 (local SQLite DB with 12 schema migrations, Viewer dashboard on port 18799, embedding_retry_queue, local ONNX embeddings). However, this repository (MemOS-Cloud-OpenClaw-Plugin, npm @memtensor/memos-cloud-openclaw-plugin v0.1.19) contains none of that code — it is a thin HTTP lifecycle plugin for MemOS Cloud with only 22 tracked files and zero SQLite/migration/viewer/ONNX code across its entire 241-commit git history. Is this issue filed against the wrong repository?
2. If so, which repository hosts the memos-local-plugin v2.0.x source (with the 12 SQL migration files where CREATE TABLE chunks is missing)? Past autodev specs reference monorepo paths like apps/memos-local-plugin/bridge.cts, suggesting a separate (possibly private) monorepo.
3. Should this issue be transferred/re-triaged to that repository so the autodev pipeline can run against the correct codebase, or is there an alternative action you expect in THIS repo (e.g. documentation note only)?
   Suggested default assumption: Confirm the issue is misfiled: transfer issue [Bug] memos-local-plugin : chunks table never created — causes viewer dashboard data drift and auto-recall injection failure #2131 to the repository that hosts the memos-local-plugin v2.0.x source (the monorepo containing apps/memos-local-plugin/ and its 12 SQL migration files), then re-run autodev there. The actual fix belongs in that repo: add an idempotent migration (e.g. migration 13) with CREATE TABLE IF NOT EXISTS chunks (...) matching the v1.0 sqlite.ts schema plus any v2.0 columns the retrieval pipeline expects, so existing v2.0.x installs self-heal on upgrade. No code change is applicable in MemOS-Cloud-OpenClaw-Plugin.
   The suggested default is only used if a maintainer explicitly confirms it.
   Please reply with one of the following commands (only issue author or repo collaborators):

• /autodev confirm yes — agree and continue with the suggested default assumption
• /autodev confirm no <additional info> — provide more details
• /autodev cancel — cancel this task
  If there is no reply within 24h, AutoDev will cancel this task using the same outcome as /autodev cancel. It will not continue with the suggested default automatically.

[MacQimw]

/autodev confirm yes

To add some context:

1. You are correct — this issue is misfiled. The bug is in @memtensor/memos-local-plugin v2.0.x, whose source code lives in apps/memos-local-plugin/ within the MemTensor/MemOS monorepo (public, not private).

2. The auto-transfer issue: We originally filed this issue 4 times in MemTensor/MemOS (both via GitHub API and web UI), but every issue gets automatically transferred to this Cloud plugin repo. This appears to be a repo-level configuration in MemOS that routes all plugin-related issues here. We are unable to bypass this behavior.

3. The correct fix is exactly what you described — add an idempotent migration (e.g. migration 013) with CREATE TABLE IF NOT EXISTS chunks (...) matching the v1.0 schema plus any v2.0 columns the retrieval pipeline expects. This should be done in MemTensor/MemOS/apps/memos-local-plugin/core/storage/migrations/.

4. Can the team help transfer this issue back to MemTensor/MemOS? Or alternatively, if the fix can be applied from this repo via a PR to the monorepo, that works too. We just want to make sure the fix lands in the right codebase.

Thank you for the thorough analysis — your suggested default assumption is spot on.