openclaw - 💡(How to fix) Fix Bug: in-turn auto-compaction can bypass memoryFlush because memoryFlush only runs pre-turn [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#62420Fetched 2026-04-08 03:04:30
View on GitHub
Comments
0
Participants
1
Timeline
0
Reactions
0
Author
Participants

When agents.defaults.compaction.memoryFlush.enabled=true, OpenClaw can still perform an in-turn auto-compaction without writing any memory files.

The root cause appears to be that runMemoryFlushIfNeeded() only runs before the turn starts, while some auto-compactions happen during the turn. In that case, compaction completes, but memory flush is never retried.

Error Message

  • Session later shows a real compaction event in the session transcript / JSONL
  • No memory/*.md write happens for that compaction cycle
  • /status may still show Compactions: 0 at some points, so the session transcript is a more reliable source than the status card
  • This is not caused by the session-memory hook being disabled; that hook is only for /new and /reset

Root Cause

The root cause appears to be that runMemoryFlushIfNeeded() only runs before the turn starts, while some auto-compactions happen during the turn. In that case, compaction completes, but memory flush is never retried.

RAW_BUFFERClick to expand / collapse

Summary

When agents.defaults.compaction.memoryFlush.enabled=true, OpenClaw can still perform an in-turn auto-compaction without writing any memory files.

The root cause appears to be that runMemoryFlushIfNeeded() only runs before the turn starts, while some auto-compactions happen during the turn. In that case, compaction completes, but memory flush is never retried.

Observed behavior

  • Session later shows a real compaction event in the session transcript / JSONL
  • No memory/*.md write happens for that compaction cycle
  • /status may still show Compactions: 0 at some points, so the session transcript is a more reliable source than the status card
  • This is not caused by the session-memory hook being disabled; that hook is only for /new and /reset

Expected behavior

If compaction.memoryFlush.enabled=true, then actual auto-compaction paths should not bypass memory flush.

At minimum, one of these should happen:

  1. Run memory flush immediately before any runtime-triggered auto-compaction
  2. Or run a best-effort post-compaction flush / audit when compaction occurred without a prior flush
  3. Or document clearly that memoryFlush only applies to pre-turn checks and does not cover in-turn auto-compaction

Why this is happening (code path)

From the current runtime flow in dist/agent-runner.runtime-C-sR1PRP.js:

  • runPreflightCompactionIfNeeded(...)
  • runMemoryFlushIfNeeded(...)
  • then the actual turn starts

In runReplyAgent(...), runMemoryFlushIfNeeded() is called before the main turn execution.

Later, during the actual turn, the runtime can emit compaction events (evt.stream === "compaction"), and the session compaction count is incremented afterward — but there is no corresponding memory flush retry on that path.

So the current behavior is effectively:

  • pre-turn: maybe flush
  • in-turn: maybe auto-compact
  • but no flush is retried if compaction happens later during the turn

Impact

This creates a misleading configuration/behavior mismatch:

  • config says memory flush is enabled
  • real compaction happens
  • but no durable memory file is written

For users, this looks like "memoryFlush is enabled but does not actually protect all compaction cases".

Environment

  • OpenClaw: 2026.3.28
  • Runtime: direct
  • Channel: Discord thread session
  • compaction.mode: safeguard
  • compaction.memoryFlush.enabled: true

Suggested fix

Make runtime-triggered auto-compaction paths call the same flush logic (or a safe subset of it), instead of limiting memoryFlush to pre-turn execution only.

extent analysis

TL;DR

Modify the runtime-triggered auto-compaction paths to call the memory flush logic to ensure consistency with the compaction.memoryFlush.enabled configuration.

Guidance

  • Review the runReplyAgent function in dist/agent-runner.runtime-C-sR1PRP.js to identify where runMemoryFlushIfNeeded can be called after a compaction event occurs during the turn.
  • Consider adding a post-compaction flush or audit when a compaction occurs without a prior flush to handle cases where runMemoryFlushIfNeeded is not called before the compaction.
  • Update the documentation to clearly state whether memoryFlush applies to pre-turn checks, in-turn auto-compaction, or both, to avoid configuration/behavior mismatches.
  • Verify the fix by checking for memory/*.md writes after auto-compactions and ensuring the session transcript and status card reflect the correct compaction count.

Example

// Pseudo-code example of calling runMemoryFlushIfNeeded after compaction
if (evt.stream === "compaction") {
  // Increment session compaction count
  // ...
  runMemoryFlushIfNeeded(); // Retry memory flush after compaction
}

Notes

The suggested fix assumes that the runMemoryFlushIfNeeded function can be safely called multiple times without adverse effects. Additional testing may be necessary to ensure the fix does not introduce new issues.

Recommendation

Apply the workaround by modifying the runtime-triggered auto-compaction paths to call the memory flush logic, as this will provide a more consistent behavior with the compaction.memoryFlush.enabled configuration.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

If compaction.memoryFlush.enabled=true, then actual auto-compaction paths should not bypass memory flush.

At minimum, one of these should happen:

  1. Run memory flush immediately before any runtime-triggered auto-compaction
  2. Or run a best-effort post-compaction flush / audit when compaction occurred without a prior flush
  3. Or document clearly that memoryFlush only applies to pre-turn checks and does not cover in-turn auto-compaction

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING