openclaw - 💡(How to fix) Fix Dreaming narrative generation fails for all but 1 agent due to concurrent fire-and-forget API calls [1 comments, 2 participants]

Summary

The dreaming system's narrative generation (generateAndAppendDreamNarrative) uses queueMicrotask() + detachNarratives = true when triggered via cron, causing all workspace narrative API calls to fire simultaneously. With N workspaces × 2 phases (light + REM) ≈ 20+ concurrent LLM API calls, most providers rate-limit and only the first succeeds. The .catch(() => void 0) pattern silently swallows all failures.

Steps to reproduce

1. Configure multiple agents with separate workspaces (e.g., 5-10)
2. Enable dreaming with "frequency": "17 3 * * *" in memory-core plugin config
3. Wait for a dreaming cycle, or trigger it manually
4. Observe: only 1 workspace gets a DREAMS.md narrative entry; the rest produce no narrative text

Note: the core memory dreaming (light/REM/deep sleep raw data) works correctly for all agents. Only the LLM-generated diary narrative is affected.

Root cause

In dreaming-IJthLYjI.js, detachNarratives is always true for cron triggers:

detachNarratives = params.trigger === "cron"

Combined with the fire-and-forget pattern:

if (params.detachNarratives)
  queueMicrotask(() => {
    generateAndAppendDreamNarrative({...}).catch(() => void 0);
  });
else
  await generateAndAppendDreamNarrative({...});

The outer loop iterates all workspaces and phases (runShortTermDreamingPromotionIfTriggered), so every workspace's narrative call fires as a microtask concurrently. DeepSeek, OpenAI, and similar providers reject or queue concurrent requests from the same API key, resulting in all but the first call being rate-limited. Because errors are silently swallowed, there is no log evidence unless you inspect the "narrative generation produced no text" debug output.

Additionally, there is a 15-second timeout (NARRATIVE_TIMEOUT_MS = 15e3) which can compound the issue when calls are queued server-side.

Suggested fix

Option A — Remove detachNarratives and always await sequentially within the workspace loop. Simplest fix; guarantees every workspace gets a narrative. The dreaming cycle already runs asynchronously in the background, so the performance impact is negligible.

Option B — Keep concurrency but add a configurable limiter (e.g., p-limit with concurrency 1-3) plus retry with exponential backoff. More complex but retains parallelism for very large deployments.

Option C — Batch all workspace snippets into a single narrative generation call per cycle, producing one diary entry covering all agents, then fan out to individual DREAMS.md files.

Environment

• OpenClaw 2026.4.27
• macOS arm64
• DeepSeek API (also reproducible with Moonshot API)
• 10 workspaces configured