Heartbeat / NO_REPLY turns may still trigger autoRecall injection and cause compaction-related latency

[flyawayzack]

Summary

We observed severe reply delays in OpenClaw Web UI that were strongly correlated with heartbeat turns and memory-lancedb-pro auto-recall injection.

After investigation, the issue appears to be caused by a combination of:

• heartbeat turns being processed too much like normal conversation turns
• memory-lancedb-pro auto-injecting <relevant-memories> during before_agent_start
• compaction being triggered but then cancelled by safeguard because there are "no real conversation messages to summarize"

Disabling heartbeat and setting autoRecall: false made the system recover immediately: no more repeated compacting context, and normal reply latency returned.

What we observed

1) Heartbeat turns seem to enter the normal prompt-building path

Our heartbeat prompt is NO_REPLY.

In practice, these heartbeat turns did not behave like a minimal health-check / HEARTBEAT_OK path. Instead, they seemed to be treated like normal turns, and we could see suspiciously long context being built around them.

2) Auto-recall appears to inject memories even for heartbeat-like turns

We observed that NO_REPLY heartbeat turns appeared to receive LanceDB memory injection, resulting in unexpectedly long prompt context.

This is especially surprising because heartbeat turns are low-value system pulses and should ideally not trigger long-term memory recall at all.

3) Compaction safeguard repeatedly cancelled compaction

We captured logs like:

Compaction safeguard: cancelling compaction with no real conversation messages to summarize.
memory-lancedb-pro: injecting 3 memories into context for agent main

This suggests a bad interaction:

1. context grows
2. compaction triggers
3. safeguard sees too few real user/assistant messages
4. compaction is cancelled
5. auto-recall continues injecting memories
6. latency becomes minutes long

Related existing issues

This seems related in spirit to several existing issues:

• 使用记忆增强插件，对话过程周期性出现长期记忆。怎么设置不出现？ #13 periodically showing long-term memories in replies
• autoRecall 绕过了框架层 memorySearch.enabled 开关 #58 autoRecall bypasses framework-level memorySearch.enabled
• Make autoRecall injection safer and less likely to leak verbatim #85 Make autoRecall injection safer and less likely to leak verbatim
• autoRecall retrieval query not stripped of OpenClaw metadata — wrong memories returned #100 autoRecall retrieval query not stripped of OpenClaw metadata

So while this report is specifically about heartbeat interaction, it may share the same root family: autoRecall boundary/gating is too broad, and metadata/system turns can pollute recall behavior.

Current workaround

The following workaround restored normal behavior for us:

{
  "agents": {
    "defaults": {
      "heartbeat": {
        "every": "0",
        "model": "aihubmix-router/gpt-5-nano",
        "prompt": "NO_REPLY",
        "lightContext": true
      }
    }
  },
  "plugins": {
    "entries": {
      "memory-lancedb-pro": {
        "config": {
          "autoRecall": false
        }
      }
    }
  }
}

Suggested fix / expected behavior

I think heartbeat / system-pulse turns should be excluded from generic auto-recall by default.

Suggested behavior:

1. Do not trigger autoRecall for heartbeat / NO_REPLY / system-event turns
2. Prefer lightContext: true or equivalent minimal context path for heartbeat
3. Strip framework metadata before any recall gating / retrieval query construction
4. Improve logs when compaction is cancelled, e.g. indicate how much of recent context comes from system events / memory injections / heartbeat turns

Why this matters

Heartbeat is supposed to be a tiny health pulse. If it can trigger memory injection and normal prompt-building, it can become a silent context amplifier that degrades the main session over time.

In our case, turning off autoRecall solved the practical problem. But if heartbeat still enters the normal path, there may still be a framework-side issue worth fixing.

Happy to provide more environment details or logs if useful.

[AliceLJY]

This is being addressed by PR #148 (fix/skip-heartbeat-autorecall), currently under review.

The PR adds explicit skip patterns to shouldSkipRetrieval() in src/adaptive-retrieval.ts that match NO_REPLY, HEARTBEAT_OK/FAIL/ERROR, health_check, system_check, and similar variants — so these turns will be short-circuited before the recall pipeline runs. It also adds a normalizeQuery() step to strip bracket-wrapped heartbeat prefixes (e.g. [heartbeat] ...) from query strings.

This directly covers the scenario you described: heartbeat turns entering the normal prompt-building path and triggering <relevant-memories> injection.

Your current workaround (autoRecall: false + heartbeat.every: 0) is the right short-term fix. Once PR #148 lands, heartbeat turns will be dropped at the retrieval gate without requiring autoRecall to be disabled globally.

The broader family of issues you linked (#58, #85, #100) — autoRecall boundary being too broad — is also being tracked. PR #141 specifically addresses the memorySearch.enabled bypass case.