openclaw - 💡(How to fix) Fix Regression: 2026.4.29 adds 30-100s pre-response latency for simple replies/heartbeats [1 comments, 2 participants]

Summary

After updating from 2026.4.27 to 2026.4.29, simple direct replies and heartbeat replies started paying a large pre-response latency tax. Before the update, simple replies were typically ~3s. On 2026.4.29, the user-visible behavior is often ~30s and sometimes close to ~100s before the assistant/model response begins.

This looks related to active-memory / embedded-run setup overhead, but the local logs also show gateway event loop stalls and Telegram/network timeout interaction, so I am filing this as a broader regression report. It may overlap with #75412; this issue adds end-user regression timing and additional log symptoms from the same version.

Environment

• OpenClaw: 2026.4.29 (a448042) stable, npm latest / up to date
• Previous version observed before regression: 2026.4.27 (cbc2ba0)
• OS: macOS 26.3.1 arm64
• Node: 25.9.0
• Gateway: local loopback, reachable in ~29-35ms, LaunchAgent running
• Memory: enabled via memory-core; active-memory is running before eligible replies
• Channel observed: direct WebChat / heartbeat; Telegram plugin also configured and producing network timeout logs

Expected behavior

A simple direct reply or heartbeat with no meaningful work should start the main assistant response quickly, roughly the pre-update behavior (~3s), and active-memory should not block the user-visible reply path for tens of seconds.

Actual behavior

On 2026.4.29, simple replies frequently wait for active-memory / embedded-run work before the main response. Examples from recent local logs:

active-memory: start timeoutMs=15000 queryChars=457
[trace:embedded-run] prep stages ... phase=stream-ready totalMs=10548
  core-plugin-tools:4894ms
  bundle-tools:496ms
  system-prompt:1866ms
  session-resource-loader:448ms
  stream-setup:2801ms
embedded run timeout ... timeoutMs=15000
embedded_run_failover_decision ... decision=surface_error ... failoverReason=timeout ... fallbackConfigured=false ... timedOut=true aborted=true
active-memory: done status=ok elapsedMs=33245 summaryChars=129

Other active-memory runs in the same session:

active-memory done status=empty elapsedMs=29880
active-memory done status=ok elapsedMs=30097
active-memory done status=empty elapsedMs=23463
active-memory done status=ok elapsedMs=23941
active-memory done status=ok elapsedMs=32687

Embedded-run prep stages repeatedly spend ~10s before stream-ready, with the largest fixed costs in core-plugin-tools, system-prompt, and stream-setup:

[trace:embedded-run] prep stages ... phase=stream-ready totalMs=10000
  core-plugin-tools:4946ms
  bundle-tools:496ms
  system-prompt:1851ms
  session-resource-loader:467ms
  stream-setup:2233ms

Gateway liveness warnings around the same period show event loop stalls, including one severe ~84s stall:

liveness warning: reasons=event_loop_delay interval=40s eventLoopDelayP99Ms=4697.6 eventLoopDelayMaxMs=10385.1 eventLoopUtilization=0.858 cpuCoreRatio=0.878 active=1 queued=1
liveness warning: reasons=event_loop_delay,event_loop_utilization,cpu interval=86s eventLoopDelayP99Ms=84423 eventLoopDelayMaxMs=84423 eventLoopUtilization=1 cpuCoreRatio=1.005 active=1 queued=1

There are also repeated bundled dependency staging logs and Telegram fetch timeouts around the same window:

[plugins] acpx staging bundled runtime deps (45 specs) ... installed bundled runtime deps in 2-5ms
[plugins] memory-core staging bundled runtime deps (45 specs) ... installed bundled runtime deps in 4-5ms
fetch timeout reached; aborting operation ... https://api.telegram.org/.../getMe
telegram/network fetch fallback: enabling sticky IPv4-only dispatcher (codes=ETIMEDOUT,ENETUNREACH)
[channels] failed to load bundled channel telegram: Cannot find module 'grammy'

Notes / possible suspect areas

• Active-memory currently appears to block or heavily delay the reply path even when it returns empty or times out.
• This may be the same root cause as #75412, but the measured end-user regression here is worse than the fixed 16-18s setup overhead described there: local runs show ~23-33s active-memory latency and one gateway event-loop stall of ~84s.
• The embedded-run prep breakdown points at fixed setup work before stream-ready, especially core-plugin-tools, system-prompt, and stream-setup.
• Telegram network timeouts / missing grammy warnings may be a compounding factor, because gateway event loop delay spikes occur near fetch timeout logs.

Reproduction sketch

1. Run OpenClaw 2026.4.29 with memory enabled and active-memory configured for direct chats.
2. Send a simple direct WebChat message or wait for a heartbeat that should result in HEARTBEAT_OK / no meaningful work.
3. Observe that the main assistant reply is delayed while active-memory embedded runs execute or time out.
4. Inspect openclaw logs --local-time --plain for active-memory, [trace:embedded-run], embedded run timeout, and event_loop_delay entries.