AM embedded run aborts memory_search tool calls; classifies as timeout despite model completion

Version

OpenClaw 2026.4.26 (commit be8c246), running on .npm-global/lib/node_modules/openclaw/openclaw.mjs per governance/UPGRADE-SOP-NATIVE.md.

Plugin

active-memory (stock plugin, dist/extensions/active-memory/index.js).

Summary

Active Memory's embedded recall sub-agent has four correlated findings that together break AM functionality on a healthy gateway:

1. AM produced status=timeout with summaryChars=0 across 5 sequential trigger runs spanning 2 different models and 2 different timeout budgets. Pass 5 enabled persistTranscripts: true; the persisted transcript shows every memory_search call from inside the embedded run returned "Aborted" (isError: true). Passes 1-4 produce the same status-line pattern but did not capture transcripts.
2. The same memory_search call from a non-embedded session works correctly (1.656s, returns hits/empty cleanly, no abort) — isolating the bug to embedded-runner / AM tool bridge / abort propagation, not memory-core globally.
3. The embedded runner classifies the run as status=timeout even when the assistant returns a normal NONE response in ~18s, well under the configured 60s budget.
4. Prior-run prompt-error events leak into the next run's context as injected custom:openclaw:prompt-error events.

Reproduction

Trent (the AM-eligible agent on this deployment) is on openai-codex/gpt-5.5 session. AM config tested across 5 runs:

Pass 5's persisted transcript at ~/.openclaw/plugins/active-memory/transcripts/agents/trent/active-memory/active-memory-mokgeyo1-780d30df.jsonl shows:

19:36:18.009Z  session start
19:36:18.851Z  model_change → ollama-cloud/minimax-m2.5
19:36:19.091Z  prompt-error injected: "active-memory timeout after 60000ms | active-memory timeout after 60000ms"
                (bug 4 — stale prompt-error from prior pass leaks into this run)
19:36:19.107Z  user message (system prompt + recent context + trigger)
19:36:28.246Z  assistant: 9s reasoning, calls memory_search({query: "...", maxResults: 3})
19:36:28.250Z  toolResult: {content: [{type:"text",text:"Aborted"}], isError: true}
19:36:29.939Z  assistant retries with simpler query → toolResult: "Aborted"
19:36:31.670Z  assistant retries again → toolResult: "Aborted"
19:36:36.262Z  assistant: returns "NONE" (correct fallback per system prompt instructions)
19:36:36.519Z  embedded run: failover decision, reason=timeout, decision=surface_error
                (bug 3 — model returned NONE in 18s; classified timeout anyway)

Disambiguation test

From a non-embedded session on the same host/runtime: memory_search invoked directly completed in 1656ms, returned 0 hits, no abort. The same memory tool path is reachable outside the AM embedded run; only the AM embedded path aborts.

Conclusion

The bug is in the embedded runner's tool dispatch / abort propagation path, NOT in memory-core or the recall model. Specifically:

• Whatever signals "abort" to the tool result is firing for every memory_search call within the embedded sub-agent
• The model eventually handles it gracefully by returning NONE (note: it violates the prompt's one-tool-stop instruction by retrying 3x first, but it converges to a valid answer)
• But the embedded runner declares the run a timeout even when the model returned cleanly within budget

System config (relevant excerpts)

{
  "plugins.entries.active-memory": {
    "enabled": true,
    "config": {
      "enabled": true,
      "agents": ["trent"],
      "allowedChatTypes": ["direct"],
      "queryMode": "recent",
      "promptStyle": "balanced",
      "timeoutMs": 60000,
      "maxSummaryChars": 220,
      "persistTranscripts": true,
      "logging": true,
      "model": "ollama-cloud/minimax-m2.5",
      "modelFallback": "ollama-cloud/minimax-m2.5"
    }
  }
}

tools.allow = [], tools.alsoAllow = []. Provider ollama-cloud configured with minimax-m2.5 allowlisted. Direct memory tool path on this host is responsive (per disambiguation test above) — failure scope is the AM embedded run.

Source pointers

• dist/extensions/active-memory/index.js — around getModelRef candidates list (function definition at line 858, candidates array at lines 865-870 in this build) — chain-resolution model selection. (Related but separate doc/UX bug — see related filing.)
• dist/extensions/active-memory/index.js — around the runEmbeddedPiAgent invocation (in this build, transcript path wiring runs roughly lines 893-955).
• The Aborted toolResult appears to be coming from the embedded runner's abort controller. We did not narrow further — likely needs source-side investigation around the AM tool bridge / sub-agent setup path.

Suggested remediation areas (not authoritative — investigation needed)

1. Investigate why memory_search tool dispatch aborts inside embedded runs. Compare embedded vs direct tool dispatch path.
2. Embedded-run timeout classification should respect model completion. If the model returns within budget (whether useful content OR NONE), status=ok is the correct classification.
3. Clear prior-run prompt-error events from the next-run context. Cross-run state leakage of error metadata is unexpected.

Impact

AM is functionally unusable on this deployment until the embedded-runner abort-propagation issue is fixed. All cloud-recall-model tuning and budget tuning are dead-end paths because the model never gets useful tool results regardless of model speed. Documented in 5 sequential test passes with controlled variable changes.

Reporter

islandpreneur007, with diagnostic support from Trent.