PR #72852: fix(memory-core): raise NARRATIVE_TIMEOUT_MS from 15s to 60s

• Repository: openclaw/openclaw
• Author: RayWoo
• State: closed | merged: True
• Link: https://github.com/openclaw/openclaw/pull/72852

Description (problem / solution / changelog)

What

Bumps NARRATIVE_TIMEOUT_MS in extensions/memory-core/src/dreaming-narrative.ts from 15 s → 60 s, and updates the matching unit-test assertion.

Why

Closes #72837.

On v2026.4.25 stable, narrative generation reliably times out for all three dreaming phases (light, REM, deep) regardless of gateway warm-up state. The memory.dream.completed event for each phase fires correctly (the underlying dream report is written to disk) but the prose-summary subagent run hits the 15 s limit before completion, so the diary entry is dropped and the gateway logs:

memory-core: narrative generation ended with status=timeout for <phase> phase.

The 15 s limit predates current model latencies — even unblocked LLM calls (OpenAI gpt-5.4-mini over a healthy network, p50 ≈ 3 s, p99 ≈ 12 s) brush against it on the first sweep after a restart, and reliably exceed it during load. Two consecutive openclaw cron run <jobId> triggers on the same machine 22 minutes apart both timed out for all 3 phases — full evidence in the linked issue.

Why 60 s (not raised further, not made configurable)

The existing comment above the constant captured the maintainer's concern explicitly:

// Narrative generation is best-effort. Keep the timeout short so a stalled // diary subagent does not leave the parent dreaming cron job "running" for // minutes after the reports have already been written.

60 s preserves that constraint — it's still well under "minutes" (plural) — while giving realistic LLM-call headroom. I considered exposing this as a dreaming.execution.narrativeTimeoutMs config field but CONTRIBUTING.md notes that new features generally aren't accepted, and a single constant bump is a tighter scope. Happy to convert to a config knob in a follow-up if you'd prefer that shape.

The new comment block reflects the empirical reasoning so a future reader doesn't need to dig through the issue history.

Testing

• dreaming-narrative.test.ts "skips extra settle waits after timeout and still attempts cleanup" hard-codes the constant (expect(...).toMatchObject({ timeoutMs: 15_000 })); updated to 60_000 to match.
• Local pnpm install not run (this fork is on a Linux host without a provisioned monorepo dev env; pulling all transitive deps was out of scope). Change is a literal-value swap with no logic or call-graph effect, so CI is the right verification surface.
• No new tests added — the existing assertion already exercises the call path; adding a separate test for "timeout is 60_000" would just duplicate what's there.

Diff size

extensions/memory-core/src/dreaming-narrative.test.ts |  2 +-
extensions/memory-core/src/dreaming-narrative.ts      | 11 ++++++++---
2 files changed, 9 insertions(+), 4 deletions(-)

Related

• #72837 — issue this closes
• #69487 — closed bug about cold-start narrative timeouts; the resolution there assumes plugin-host warm-up explains the latency, but #72837 shows the timeout still fires on warm gateways with the plugin runtime fully loaded — so this PR addresses the underlying budget rather than the warm-up path

Changed files

• extensions/memory-core/src/dreaming-narrative.test.ts (modified, +1/-1)
• extensions/memory-core/src/dreaming-narrative.ts (modified, +8/-3)