fix(memory-core): raise NARRATIVE_TIMEOUT_MS from 15s to 60s#72852
Conversation
Greptile SummaryRaises Confidence Score: 5/5Safe to merge — minimal, well-scoped constant bump with no logic changes and a correctly updated test. No logic, interface, or call-graph changes. The constant is defined in one place and consumed in one place; the matching test assertion was updated consistently; no other references to the old value remain. No files require special attention. Reviews (1): Last reviewed commit: "fix(memory-core): raise NARRATIVE_TIMEOU..." | Re-trigger Greptile |
2889b32 to
8292515
Compare
Closes openclaw#72837. The 15s narrative-subagent timeout was empirically too tight for warm-gateway runs across light, REM, and deep phases — gpt-5.4-mini latency through OpenAI alone routinely brushes 12s+, so the first sweep after a restart deterministically times out across all three phases. 60s gives realistic LLM-call headroom while still capping the worst case at one minute, preserving the original comment's "don't leave parent cron running for minutes" constraint. Test: updates the matching toMatchObject assertion in dreaming-narrative.test.ts from 15_000 to 60_000.
8292515 to
962fe46
Compare
What
Bumps
NARRATIVE_TIMEOUT_MSinextensions/memory-core/src/dreaming-narrative.tsfrom 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.completedevent 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:The 15 s limit predates current model latencies — even unblocked LLM calls (OpenAI
gpt-5.4-miniover 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 consecutiveopenclaw 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:
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.narrativeTimeoutMsconfig field butCONTRIBUTING.mdnotes 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 to60_000to match.pnpm installnot 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.Diff size
Related