openclaw - ✅(Solved) Fix [Bug] Active Memory plugin times out on every run (15s timeout, 0 chars output) - v2026.4.26 [1 pull requests, 4 comments, 3 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#73306Fetched 2026-04-29 06:21:10
View on GitHub
Comments
4
Participants
3
Timeline
16
Reactions
2
Timeline (top)
subscribed ×6commented ×4mentioned ×4cross-referenced ×2

Active Memory plugin consistently times out on every run since upgrading to v2026.4.26 (also occurred on v2026.4.25). The plugin starts, hits the 15s timeout, returns 0 summary chars, and the embedded run fails over with surface_error.

Related issues: #68825, #66708, #66157, #65159

Root Cause

Active Memory plugin consistently times out on every run since upgrading to v2026.4.26 (also occurred on v2026.4.25). The plugin starts, hits the 15s timeout, returns 0 summary chars, and the embedded run fails over with surface_error.

Related issues: #68825, #66708, #66157, #65159

Fix Action

Workaround

Disabling active-memory resolves the timeout, but removes automatic memory surfacing.

PR fix notes

PR #73219: feat(active-memory): return partial transcript on timeout

Description (problem / solution / changelog)

Summary

When the active-memory recall subagent hits its configured timeoutMs or is otherwise aborted, the plugin currently discards the partial output the embedded Pi agent has already written to the session transcript. This PR recovers that work.

Motivation

Recall runs commonly produce a useful summary in the first 30-60s, then hit timeoutMs while the model is still finishing. Today the user gets nothing — { status: "timeout", summary: null } — and the partial transcript is silently dropped.

Change

  • New timeout_partial variant in ActiveRecallResult.
  • readPartialAssistantText(sessionFile) reads the JSONL on timeout, joins assistant text, returns null if empty.
  • Two timeout paths (race-loss, abort-during-await) now return timeout_partial when partial text is recoverable, or timeout (unchanged) when nothing was written.
  • Status line, prompt prefix, and metadata surface partial output the same way ok does.
  • Caching only fires for ok (no caching of partial output).
  • Generic-error unavailable path unchanged.

Tests

7 new tests in extensions/active-memory/index.test.ts cover:

  1. Timeout with partial transcript → timeout_partial
  2. Timeout with empty transcript → timeout
  3. Timeout with no transcript path → timeout
  4. Abort-during-await with partial → timeout_partial
  5. Generic error path unchanged → unavailable
  6. shouldCacheResult(timeout_partial) === false
  7. Status line / prompt prefix / metadata all reflect partial summary

Backward compatibility

timeout_partial is a new discriminant; existing callers that exhaustively switch on result.status will get a TS error and need to handle it explicitly (intentional — partial output should be surfaced, not silently treated as full timeout).

Notes

Reported by Joey Krug; the live config currently has timeoutMs: 90000 on Sonnet 4.6 and was hitting timeouts on long-context Signal recalls.

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • extensions/active-memory/index.test.ts (modified, +459/-0)
  • extensions/active-memory/index.ts (modified, +351/-72)

Code Example

{
  "active-memory": {
    "enabled": true,
    "config": {
      "enabled": true,
      "agents": ["telegram-chat"],
      "allowedChatTypes": ["direct"],
      "model": "openrouter/google/gemini-2.5-flash-lite",
      "queryMode": "recent",
      "promptStyle": "recall-heavy",
      "timeoutMs": 15000,
      "maxSummaryChars": 220
    }
  }
}

---

active-memory: agent=telegram-chat session=agent:telegram-chat:main activeProvider=openrouter activeModel=google/gemini-2.5-flash-lite start timeoutMs=15000 queryChars=926
active-memory: agent=telegram-chat session=agent:telegram-chat:main activeProvider=openrouter activeModel=google/gemini-2.5-flash-lite done status=timeout elapsedMs=15004 summaryChars=0
embedded_run_failover_decision: failoverReason=timeout provider=openrouter model=google/gemini-2.5-flash-lite timedOut=true aborted=true
RAW_BUFFERClick to expand / collapse

Summary

Active Memory plugin consistently times out on every run since upgrading to v2026.4.26 (also occurred on v2026.4.25). The plugin starts, hits the 15s timeout, returns 0 summary chars, and the embedded run fails over with surface_error.

Related issues: #68825, #66708, #66157, #65159

Environment

  • OpenClaw: 2026.4.26 (upgraded from 2026.4.25)
  • OS: macOS 26.4.1 (arm64) Mac Mini M4
  • Node: 25.8.1
  • Plugin compatibility: none

Active Memory Config

{
  "active-memory": {
    "enabled": true,
    "config": {
      "enabled": true,
      "agents": ["telegram-chat"],
      "allowedChatTypes": ["direct"],
      "model": "openrouter/google/gemini-2.5-flash-lite",
      "queryMode": "recent",
      "promptStyle": "recall-heavy",
      "timeoutMs": 15000,
      "maxSummaryChars": 220
    }
  }
}

Reproduction

  1. Enable Active Memory plugin with OpenRouter as provider
  2. Send any message via Telegram
  3. Every active-memory run times out at 15s with 0 summary chars

Log Evidence

active-memory: agent=telegram-chat session=agent:telegram-chat:main activeProvider=openrouter activeModel=google/gemini-2.5-flash-lite start timeoutMs=15000 queryChars=926
active-memory: agent=telegram-chat session=agent:telegram-chat:main activeProvider=openrouter activeModel=google/gemini-2.5-flash-lite done status=timeout elapsedMs=15004 summaryChars=0
embedded_run_failover_decision: failoverReason=timeout provider=openrouter model=google/gemini-2.5-flash-lite timedOut=true aborted=true

Key Observations

  1. OpenRouter API itself works fine — direct curl to the same model returns in ~0.6s
  2. The timeout is in the plugin layer, not the API
  3. openclaw status shows Plugin compatibility: none — may be related
  4. Memory search (memorySearch) works perfectly — only active-memory plugin is affected
  5. Issue persists across gateway restarts
  6. Channels table in openclaw status is also empty (channels work fine via openclaw channels status)

Workaround

Disabling active-memory resolves the timeout, but removes automatic memory surfacing.

Full Status Output

Plugin compatibility: none
Memory: 965 files · 2609 chunks · sources memory · plugin memory-core · vector ready · fts ready · cache on (6290)
``

extent analysis

TL;DR

The Active Memory plugin timeout issue may be resolved by adjusting the plugin configuration or investigating the compatibility issue indicated by "Plugin compatibility: none".

Guidance

  • Verify that the OpenRouter API endpoint and model are correctly configured and accessible, as the direct curl test suggests the API itself is working fine.
  • Investigate the "Plugin compatibility: none" status and its potential impact on the Active Memory plugin, as this might be a contributing factor to the timeout issue.
  • Consider temporarily adjusting the timeoutMs value in the Active Memory config to a higher value to see if the issue persists, which could help determine if the timeout is due to the plugin or an external factor.
  • Review the differences between the working memorySearch functionality and the Active Memory plugin to identify potential discrepancies in configuration or implementation.

Example

No specific code snippet is provided due to the lack of direct code references in the issue, but adjusting the timeoutMs value could look like modifying the JSON config:

{
  "active-memory": {
    "enabled": true,
    "config": {
      "enabled": true,
      "agents": ["telegram-chat"],
      "allowedChatTypes": ["direct"],
      "model": "openrouter/google/gemini-2.5-flash-lite",
      "queryMode": "recent",
      "promptStyle": "recall-heavy",
      "timeoutMs": 30000, // Increased timeout for testing
      "maxSummaryChars": 220
    }
  }
}

Notes

The issue seems to be specific to the Active Memory plugin and its interaction with the OpenRouter API, given that other functionalities like memorySearch work as expected. The "Plugin compatibility: none" status is a significant clue that needs further investigation.

Recommendation

Apply workaround: Temporarily disable the Active Memory plugin or adjust its configuration to mitigate the timeout issue while further investigating the root cause, especially focusing on the plugin

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…

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Bug] Active Memory plugin times out on every run (15s timeout, 0 chars output) - v2026.4.26 [1 pull requests, 4 comments, 3 participants]