HybridStorageAdapter waitForQueryReady times out (60s, repeated) → embeddings skipped, MCP tool calls hang — v5.9.3, idb backend

[marketingmaniacs]

Summary

On a fresh install of Nexus 5.9.3, the HybridStorageAdapter never becomes ready — waitForQueryReady times out after 60000 ms repeatedly, the storage adapter init fails, and embeddings are skipped entirely. As a result semantic search / storage tools never work, and when Nexus is used as an MCP server every non-trivial tool call hangs until the client times out.

Environment

Nexus	5.9.3 (latest)
Obsidian	1.12.4
OS	macOS 15.7.4
Storage backend	idb (per data.json → pluginStorage.cacheBackend.backend)
Vault	~156 markdown notes, vault stored in a cloud-synced folder
Install age	Fresh install same day (little/no Nexus state yet)
MCP usage	Used as MCP server via the generated connector.js, Node v20.11.1

Symptom

Obsidian Developer Console on startup (key lines, repeated):

AppWorker exception TypeError: Cannot read properties of undefined (reading 'startsWith')
    at worker.js:1
Metadata failed to parse                                          (app.js)
[nexus] ERROR: Failed to list directory .workspaces               (plugin:nexus:6)
[HybridStorageAdapter] waitForQueryReady timed out after 60000 ms  (plugin:nexus:840)   ← repeats 47×
[PluginLifecycleManager] Storage adapter failed to initialize; skipping embeddings  (plugin:nexus:2241)

.workspaces/ does exist at vault root (with subdirectories), so it is not a missing-directory problem — the worker that backs storage appears to crash on init ("Metadata failed to parse" / startsWith on undefined), after which waitForQueryReady can never resolve.

What works vs. what doesn't

• ✅ Obsidian Local REST API plugin (running alongside) is fully healthy — GET /vault/ → 200, etc.
• ✅ Lightweight MCP calls (e.g. tool capability / --help) succeed — the connector itself is fine.
• ❌ Any MCP call that touches storage/search (search, storage list) hangs and times out after ~4 min on the client side.
• ❌ No cache.db is ever created in the plugin directory → semantic index never builds.

Storage state (data.json, sanitized)

"pluginStorage": {
  "storageVersion": 2,
  "sourceOfTruthLocation": "vault-root",
  "migration": { "state": "not_needed", "legacySourcesDetected": [], "activeDestination": "Nexus/data" },
  "cacheBackend": { "backend": "idb", "migrationState": "verified", "migratedAt": 1778832546691 }
}

cacheBackend.migrationState is "verified" with a migratedAt timestamp, yet the adapter still fails — the worker appears to read persisted metadata it cannot parse (Metadata failed to parse + Cannot read properties of undefined (reading 'startsWith')).

Impact

Storage adapter failing to initialize cascades into: no embeddings, no semantic search, and (when used as an MCP server) every storage/search tool call hangs for minutes. The plugin is effectively unusable for its core features in this state.

Notes

• Latest version (5.9.3), no matching existing issue found.
• Happy to provide the full console log, expanded error objects, or test a patch.

[marketingmaniacs]

Update — root cause confirmed and worked around

Clearing the persisted storage state resolved it. The console message flipped from:

[PluginLifecycleManager] Storage adapter failed to initialize; skipping embeddings

to:

[PluginLifecycleManager] Storage adapter ready, initializing embeddings...

What fixed it (with Obsidian closed):

• Deleted the plugin data/ directory
• Deleted the vault-root state dirs (.workspaces/, .conversations/, Nexus/)
• Removed the pluginStorage block from data.json (kept provider/other settings + the generated connector.js)
• Reopened Obsidian → storage adapter initializes fresh, embeddings begin

So the trigger appears to be corrupt/incompatible persisted storage state carried across the storage migration (cacheBackend.migrationState: "verified" with a migratedAt timestamp, yet the worker could not parse it → Metadata failed to parse / Cannot read properties of undefined (reading 'startsWith') → waitForQueryReady never resolves). A fresh install that inherited a half-migrated state reproduces it; wiping the state clears it.

Two side observations for you:

1. Startup race after a state reset: immediately after clearing state, listWorkspaceIds runs before the directory is recreated, producing repeated:
   [nexus] ERROR: Failed to list directory .workspaces … ENOENT: no such file or directory, scandir '…/.workspaces'
   (call path: prefetchWorkspaces / loadWorkspaces → listWorkspaceIds → listDirectory, during startBackgroundInitialization). Self-resolves once the dir is recreated, but it's noisy and might be worth a defensive ensureDir before listing.

2. Likely unrelated noise: app.js Metadata failed to parse fires on a Templater template note (…/Templates/Template OFS Plugin.md) — appears to be Obsidian core metadata parsing choking on template syntax, not Nexus storage. Flagging in case it's conflated.

Suggestion: detecting an unparseable/corrupt cache and auto-rebuilding (instead of timing out 60s × N then permanently skipping embeddings) would make this self-healing.

[gcp007-ops]

Cross-referencing #158: the waitForQueryReady 60s-timeout symptom also has a non-corruption path. On a large but valid store, fullRebuild() simply cannot finish within the 60s window — same console signature (waitForQueryReady timed out after 60000 ms, repeated; storage/search MCP calls hang), but the cache is not corrupt and the v5.9.5 InitLifecycleController settle-on-throw fix does not cover it (nothing throws). Detail + a root-cause profile (trace_added growing the workspace event store unbounded) is in #158. The auto-rebuild-on-corrupt-cache you suggested here, plus a rebuild timeout and trace retention, would together make both paths self-healing.

[ProfSynapse]

Shipped a hopeful fix in Nexus 5.9.6: https://github.com/ProfSynapse/nexus/releases/tag/5.9.6

The release tightens startup/query readiness recovery for the repeated waitForQueryReady timeout class: failed or stalled required rebuilds now settle as failures instead of leaving the adapter in a half-ready state, and there is now a Settings > Data > Maintenance > Rebuild cache recovery path. It also includes related trace payload reductions and additional stress coverage for large trace-heavy stores.

I'm keeping this issue open until we get confirmation from real affected vaults. It may take a bit for 5.9.6 to show up in Obsidian's community plugin updater after the GitHub release.