openclaw - 💡(How to fix) Fix [Bug]: active-memory eligibility gate accepts dreaming-narrative session keys, busts 45s lane budget on cron [1 comments, 2 participants]

Version

2026.5.5

Summary

The active-memory plugin's isEligibleInteractiveSession gate (dist/extensions/active-memory/index.js:548) is intended to filter to conversational sessions (trigger="user" + allowedChatTypes membership), but session keys produced by the memory-core dreaming-narrative cron (agent:<agent>:dreaming-narrative-{light,rem,deep}-<workspaceId>-<ts>) slip through. Each accepted invocation pays the AM cold-start cost (codex subagent setup + qmd init + bootstrap context) inside a hardcoded 45000ms command-lane budget, and reliably exceeds it.

Expected

Session keys generated by non-interactive cron paths (dreaming, digest, maintenance) should not trigger active-memory pre-prompt recall. The existing allowedChatTypes allowlist (direct|group|channel|explicit) suggests this is the intended gate.

Actual

Gateway error log shows clusters during the 3am cron window:

[lane] lane task error: lane=active-memory, error=CommandLaneTaskTimeoutError after 45000ms
  sessionKey=agent:<agent>:dreaming-narrative-light-<workspaceId>-<ts>
  sessionKey=agent:<agent>:dreaming-narrative-rem-<workspaceId>-<ts>
  sessionKey=agent:<agent>:dreaming-narrative-deep-<workspaceId>-<ts>

Three sequential narrative phases x N narratives = many cold starts back-to-back. Daytime hits on actual user sessions are rare (~2/day in my logs), so the symptom is concentrated and easy to miss as a generic "AM is slow" complaint.

Where the lane budget is set

dist/command-queue-*.js runQueueEntryTask rejects with CommandLaneTaskTimeoutError(lane, taskTimeoutMs). The 45000ms value is hardcoded per-enqueue and not exposed via the active-memory plugin schema. AM's own watchdog (timeoutMs: 15000 + setupGraceTimeoutMs: 0, see dist/extensions/active-memory/index.js:1419-1426) sits inside that budget, so the lane kills the task before AM can self-cancel.

Repro

1. Enable active-memory and memory-core (with dreaming) on the same agent.
2. Wait for the dreaming cron (or trigger a dreaming session key manually).
3. Watch gateway.err.log for lane=active-memory ... CommandLaneTaskTimeoutError after 45000ms with sessionKey containing dreaming-narrative-.

Asks (either is sufficient)

• Tighten the eligibility gate so dreaming/cron session keys are rejected before AM dispatch — most surgical fix.
• Or expose excludeSessionKeyPatterns (or analogous) on the active-memory plugin schema so operators can opt these out without a patch.

Related

• #67000 (warm-up / session reuse for embedded agents)
• #72359 (single-shot mode for active-memory)
• #74586 (AM embedded run aborts memory_search; classifies as timeout despite model completion) — different code path, but same general family of "AM dispatch creates noise that masquerades as failure".
• #76333 / PR #76463 (NARRATIVE_TIMEOUT_MS too small) — different code path, fixes a different cron timeout.

User-visible impact: low when isolated to dreaming (no quality dent on real conversations), but the noise drowns out real AM lane errors and the cold-start cost is wasted compute.