narrative generation produced no text warnings fire even when assistant messages contain extractable text

Summary

memory-core's dreaming-narrative flow logs narrative generation produced no text for {phase} phase warnings at high rate even when the underlying narrative subagent session DID produce extractable assistant text. The narratives still land in DREAMS.md (sometimes) and the warning is benign in that sense, but the misleading rate (16-19 warnings per dreaming sweep against ~17 sessions that actually contain extractable text) makes log triage significantly harder.

Versions affected

• [email protected] (a374c3a) — current; still reproduces (23-24 warnings/day on bering-sea, 2026-05-26 and 2026-05-27)
• [email protected] (a185ca2) — reproduced
• [email protected] (50a2481) — reproduced
• (didn't test earlier versions; pattern looks long-running)

Bundle hashes: the dist files are bundler-hashed per release, so the hashes below are pinned to 5.22. In 5.19 they were dreaming-phases-CC9r0Vso.js and session-utils.fs-D_3ZT9EK.js. Match by symbol (extractNarrativeText, parsedSessionEntryToMessage) not by filename if you're on a different build.

Evidence — what should and shouldn't fire

I reconstructed the extraction logic against actual post-switch session data (20 dreaming-narrative trajectories from a single manual cron trigger):

Expected log warnings: ~3. Actual log warnings: 19 for that exact run.

Method

For each post-switch trajectory file in ~/.openclaw-<profile>/agents/main/sessions/*.trajectory.jsonl:

1. Match by sessionKey starting with agent:main:dreaming-narrative-
2. Read the corresponding <sessionId>.jsonl file
3. Walk message entries; unwrap entry.message per parsedSessionEntryToMessage in session-utils.fs-CsnHXIqH.js
4. Replay extractNarrativeText(messages) from dreaming-phases-B7KNuvKO.js:
   • Walk backward, find first role === "assistant" with content
   • Return string content if non-empty, OR
   • Return joined type === "text" / type === "output_text" parts if non-empty

For 17 of 18 sessions with assistant messages, this returned valid text (1000+ chars of journal-style prose in many).

The session contents I sampled confirm the text was real:

"role": "assistant"
"content": [{"type": "text", "text": "I lay here, a light in the
            room that is still waking. The day has slipped past with
            its usual cycle of appendings and creations..."}]

Hypothesis

Three remaining possibilities, in order of my own confidence:

1. Race condition between waitForRun returning status: "ok" and the assistant message being persisted to the session JSONL. getSessionMessages reads from the persisted file; if extraction runs before flush, the file's last assistant entry could be missing or partial.

2. A separate validation layer (between waitForRun ok and the extractor) that detects rule violations or formatting issues and nulls the result. E.g., the system prompt says "Never say 'dreaming'/ 'I'm dreaming'/'as I dream'" — observed model outputs that included "I dreamed" might be silently rejected upstream, then the extractor sees nothing.

3. successfulSessionKey mismatch — waitForRun returns ok for one session key but getSessionMessages is queried with a different one (e.g., the retry session key vs the base session key).

Reproduction

Configure dreaming with a local Ollama model (this happens with any local LLM that produces narrative text). Run dreaming cron once and compare the narrative generation produced no text warning count to the number of post-cron trajectory files with non-empty assistant content.

Suggested next steps

1. Add a debug log at the getSessionMessages call inside dreaming-phases-B7KNuvKO.js showing message count + last-assistant content length. That alone should reveal whether the warning is from race, validation, or sessionKey mismatch.
2. If race-confirmed: serialize after waitForRun ok against JSONL-flush completion (or add an explicit awaitable on persistence).
3. If validation-confirmed: log WHY the candidate text was rejected, not just "no text."