Summary

lossless-claw appears to prune heartbeat acknowledgement messages as part of normal post-turn cleanup, but the event is emitted at error level in logs.

Example observed log:

12:29:37+00:00 error [lcm] afterTurn: pruned 2 heartbeat ack messages from conversation 15

The behavior itself looks normal and expected:

• post-turn hook runs
• heartbeat ack messages are identified as ignorable noise
• they are pruned from the conversation/history context

What looks wrong is the log severity. This appears to be routine housekeeping, not an error condition.

Steps to reproduce

1. Run OpenClaw with lossless-claw enabled.
2. Allow one or more heartbeat cycles to occur where the conversation receives heartbeat acknowledgement messages such as HEARTBEAT_OK.
3. Let a normal agent turn complete so the afterTurn hook runs.
4. Inspect logs.
5. Observe a line like:

error [lcm] afterTurn: pruned 2 heartbeat ack messages from conversation 15

Expected behavior

If heartbeat acknowledgement pruning is normal cleanup, it should be logged as one of:

• debug
• info

or it should be silent entirely unless verbose/debug logging is enabled.

It should not be emitted as an error unless pruning failed or caused data corruption.

Actual behavior

A normal cleanup action is logged as:

error [lcm] afterTurn: pruned 2 heartbeat ack messages from conversation 15

This makes logs look like the system is failing when it is actually doing expected maintenance.

Environment

• OpenClaw version: 2026.4.5
• lossless-claw version: 0.6.3
• OS: macos 26.4 (arm64)
• Node: 22.22.2
• Gateway mode: local
• Active workflow included heartbeat-enabled agent sessions

Logs, screenshots, and evidence

Observed log line:

12:29:37+00:00 error [lcm] afterTurn: pruned 2 heartbeat ack messages from conversation 15

Related observations:

• Message prefix is [lcm], suggesting this originates from the lossless conversation memory path
• Action described is afterTurn
• Wording suggests successful cleanup, not failure:
  • pruned 2 heartbeat ack messages

This strongly suggests a log-level mismatch rather than an actual runtime error.

Impact and severity

Severity: Low to Medium

Why this matters:

1. False alarms in logs
   • Operators may think the plugin is failing when it is not.
2. Signal-to-noise degradation
   • Real errors become harder to spot among benign cleanup messages.
3. Misleading observability
   • Normal behavior is classified as an error, which breaks trust in logs.

Suggested fix:

• Downgrade this message to debug or info
• Or suppress it unless verbose/debug logging is enabled
• Reserve error for actual pruning failures or unexpected state