openclaw - 💡(How to fix) Fix readPageSummaries: no concurrency limit on fs.readFile, triggers EDEADLK on iCloud/FileProvider-backed vaults [1 participants]

Problem

readPageSummaries in dist/cli-mPaKxVzJ.js (line 586) unbounded-parallel fs.readFiles every markdown page in the wiki vault via Promise.all(filePaths.map(readFile)). For vaults backed by iCloud Drive / macOS FileProvider (e.g. Obsidian-in-iCloud), this kernel-level parallel read burst can deadlock the provider and surface as Error: Unknown system error -11: Unknown system error -11, read (errno 11 = EDEADLK, "Resource deadlock avoided").

Symptom: openclaw wiki ingest / openclaw wiki compile either hangs forever or fails with partial reads. When reads "succeed" under stress the content can be zero-length, producing silent wiki corruption.

Reproduction

1. Put a memory-wiki vault in iCloud (vaultMode: bridge, vault path inside iCloudmdobsidian).
2. Grow it to 150+ pages.
3. Run openclaw wiki compile (or any flow that calls readPageSummaries).
4. Observe repeated memory sync failed (session-delta): Error: Unknown system error -11: Unknown system error -11, read in gateway logs.
5. fs.readFile fans out on 150+ files; iCloud FileProvider serializes reads and deadlocks under burst.

Secondary repro path (external): rsync / ditto / cat / redirected cp on the same directory reproduce EDEADLK in user space, confirming the issue is file-system-side rather than OpenClaw-specific — but OpenClaw is the one triggering the pathological pattern.

Proposed Fix

Cap concurrency at a small constant (e.g. 8) using p-limit or equivalent:

// dist source (illustrative — originals are minified)
import pLimit from "p-limit";
async function readPageSummaries(rootDir) {
  const filePaths = (await Promise.all(COMPILE_PAGE_GROUPS.map((group) =>
    collectMarkdownFiles(rootDir, group.dir)))).flat();
  const limit = pLimit(8);
  return (await Promise.all(filePaths.map((relativePath) => limit(async () => {
    const absolutePath = path.join(rootDir, relativePath);
    return toWikiPageSummary({
      absolutePath,
      relativePath,
      raw: await fs$1.readFile(absolutePath, "utf8"),
    });
  })))).flatMap((page) => page ? [page] : []).toSorted((a, b) => a.title.localeCompare(b.title));
}

Notes:

• Concurrency of 8 is a conservative default; it survives iCloud FileProvider burstiness locally.
• Same pattern is worth applying anywhere else in the wiki compile path that unbounded-Promise.alls file IO; readPageSummaries is just the most painful one.
• Consider making the limit configurable (plugins.entries.memory-wiki.config.compile.concurrency) for users who know their vault is on a fast local disk.

Environment

• OpenClaw 2026.4.15 (also repro on 2026.4.11, 2026.4.12)
• macOS 26.4.1 (Tahoe) on Apple Silicon; same issue on 15.7.3 (Sequoia) before upgrade
• Vault: Obsidian + iCloud sync, ~165 markdown pages
• cli-mPaKxVzJ.js:586 readPageSummaries, cli-mPaKxVzJ.js:1011 compileMemoryWikiVault

Workaround

Move vault out of iCloud to a local disk path (e.g. ~/.openclaw/wiki) and re-point plugins.entries.memory-wiki.config.vault.path. This avoids FileProvider entirely but breaks iCloud-based cross-device sync for users who want it.

Related

• On macOS Unknown system error -11 is EDEADLK (errno 11); not the more-famous EAGAIN (35). Deadlock, not retryable transient.