Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

The Active Memory plugin's config.timeoutMs setting (set to 15000ms) is not enforced as a hard cap on total execution time. When the initial LLM request times out, the embedded run failover chain (rotate auth profile → fallback model) adds additional retry attempts that are not bounded by timeoutMs. This results in Active Memory blocking the main reply for 40-125+ seconds instead of the configured 15 seconds.

This is a blocking issue — Active Memory runs synchronously before every reply in eligible sessions, so each timeout directly delays the user-visible response.

Steps to reproduce

Environment

• OpenClaw version: 2026.4.10 (44e5b62)
• Platform: Linux (Ubuntu 24.04), x64, Node v25.8.2
• Channel: WhatsApp (direct messages)
• Auth: Anthropic OAuth token (two profiles configured)
• Memory backend: QMD
• Context engine: lossless-claw 0.8.0

Configuration

{
  "plugins": {
    "entries": {
      "active-memory": {
        "enabled": true,
        "config": {
          "enabled": true,
          "agents": ["main"],
          "allowedChatTypes": ["direct"],
          "modelFallbackPolicy": "default-remote",
          "queryMode": "recent",
          "promptStyle": "balanced",
          "timeoutMs": 15000,
          "maxSummaryChars": 220,
          "persistTranscripts": false,
          "logging": true,
          "model": "anthropic/claude-haiku-4-5"
        }
      }
    }
  }
}

Expected behavior

config.timeoutMs: 15000 should be a hard ceiling on total Active Memory execution time, including any failover/retry attempts. If the initial request doesn't complete within 15 seconds, Active Memory should return NONE/empty and let the main reply proceed.

Actual behavior

Observed Behavior

Out of 14 Active Memory invocations in a ~40 minute window, 4 timed out with durations far exceeding the configured 15s timeout:

*Run #1 used Opus because the config.model patch hadn't restarted yet.

The remaining 10 invocations completed successfully in 1.2-2.2 seconds with status=empty or status=ok.

OpenClaw version

2026.4.10

Operating system

Ubuntu 24.04

Install method

npm global

Model

anthropic/opus-4-6

Provider / routing chain

Openclaw -> anthropic -> opus

Additional provider/model setup details

Root Cause Analysis

The failover chain operates independently of timeoutMs:

1. Initial LLM request starts
2. Request times out (per some internal timeout, not timeoutMs)
3. Failover step 1: rotate_profile — tries the same model with a different auth profile
4. That also times out
5. Failover step 2: fallback_model — tries a different model entirely
6. That also times out (or the overall lane errors out)
7. Active Memory finally returns status=timeout

Each step in the failover chain appears to get its own timeout window (~30-60s each), and timeoutMs does not abort the chain early. The timeoutMs value appears to only apply to the initial request, not the total embedded run lifecycle.

Logs, screenshots, and evidence

## Log Evidence

### Timeout #2 (125.2 seconds, Haiku)


07:33:01 [plugins] active-memory: agent=main session=agent:main:main start timeoutMs=15000 queryChars=1391
07:33:49 [agent] embedded run failover decision: runId=active-memory-mnufpo6t-6e996d78 stage=assistant decision=rotate_profile reason=timeout provider=anthropic/claude-haiku-4-5 profile=sha256:154a23a3efe6
07:34:58 [agent] embedded run failover decision: runId=active-memory-mnufpo6t-6e996d78 stage=assistant decision=fallback_model reason=timeout provider=anthropic/claude-haiku-4-5 profile=sha256:ab919eb4413a
07:34:58 [diagnostic] lane task error: lane=session:agent:main:main:active-memory:735c698d8eb1 durationMs=117120 error="FailoverError: LLM request timed out."
07:35:06 [plugins] active-memory: agent=main session=agent:main:main done status=timeout elapsedMs=125243 summaryChars=0


### Timeout #4 (123.8 seconds, Haiku)


07:57:29 [plugins] active-memory: agent=main session=agent:main:main start timeoutMs=15000 queryChars=1666
07:58:17 [agent] embedded run failover decision: runId=active-memory-mnugl5b0-1a2d5b36 stage=assistant decision=rotate_profile reason=timeout provider=anthropic/claude-haiku-4-5 profile=sha256:154a23a3efe6
07:59:33 [agent] embedded run failover decision: runId=active-memory-mnugl5b0-1a2d5b36 stage=assistant decision=fallback_model reason=timeout provider=anthropic/claude-haiku-4-5 profile=sha256:ab919eb4413a
07:59:33 [diagnostic] lane task error: lane=session:agent:main:main:active-memory:f3cb0a1f008b durationMs=123816 error="FailoverError: LLM request timed out."
07:59:33 [plugins] active-memory: agent=main session=agent:main:main done status=timeout elapsedMs=123821 summaryChars=0


### Successful run immediately after timeout #4 (same session, 1.9 seconds)


08:01:40 [plugins] active-memory: agent=main session=agent:main:main start timeoutMs=15000 queryChars=1666
08:01:42 [plugins] active-memory: agent=main session=agent:main:main done status=ok elapsedMs=1913 summaryChars=204

Impact and severity

• Every timeout blocks the user-visible reply by 40-125 seconds
• Active Memory is a blocking pre-reply step — there is no async fallback
• The pattern is intermittent (4/14 = ~29% failure rate) but severe when it hits
• WhatsApp disconnects (status 408) correlate with the long blocking periods, suggesting the connection idles out while waiting

Additional information

Suggested Fix

1. Hard timeout enforcement: timeoutMs should wrap the entire embedded run lifecycle (initial request + all failover attempts). If the total elapsed time exceeds timeoutMs, abort immediately and return empty/NONE.

2. Or: disable failover for Active Memory runs. The Active Memory plugin is latency-sensitive by design. The failover chain (rotate profile → fallback model) is appropriate for main replies but counterproductive for a blocking pre-reply sub-agent where speed matters more than resilience.

3. Or: add a separate maxTotalTimeoutMs config that caps the entire chain, independent of per-attempt timeouts.

Workaround

Disabled Active Memory (config.enabled: false) until the timeout enforcement is fixed. The feature works well when the LLM responds promptly (1-2 seconds), but the unbounded failover chain makes it unusable in production.

Additional Context

• Two Anthropic auth profiles are configured (OAuth tokens). The failover chain rotates between them before falling back to a different model.
• The main session LLM requests (Opus) are working fine during the same time window — this appears specific to the embedded Active Memory sub-agent runner.
• modelFallbackPolicy: "default-remote" was set per the docs' recommended setup. Switching to "resolved-only" might reduce the chain length but wouldn't fix the core issue of timeoutMs not being enforced.