fix(memory-core): register memory tools independently to prevent coupled failure by artwalker · Pull Request #50198 · openclaw/openclaw

artwalker · 2026-03-19T04:27:48Z

Summary

Split the coupled memory_search + memory_get tool registration in memory-core plugin into two independent registerTool calls
The previous single-factory approach returned null when either tool failed, silently dropping both tools from new sessions
Add debug logging when a plugin tool factory returns null to aid diagnosis

Root Cause

extensions/memory-core/index.ts registered both tools in one factory:

if (!memorySearchTool || !memoryGetTool) {
  return null;  // BOTH tools lost if EITHER fails
}

When the factory returned null, resolvePluginTools() silently skipped it with no log output, making the failure invisible.

Test plan

npm run build passes
Memory tool unit tests pass (10/10)
All 590 plugin tests pass (70 files)
Verify memory tools appear in new Feishu sessions with memory-core enabled

Fixes #50173

🤖 Generated with Claude Code

greptile-apps · 2026-03-19T04:29:14Z

Greptile Summary

This PR fixes a silent double-failure bug in the memory-core plugin where both memory_search and memory_get tools would be dropped from new sessions if either one failed to initialize, and adds a debug log to make future null-factory returns observable.

Changes:

extensions/memory-core/index.ts: Splits one registerTool call (registering both tools in a single factory) into two independent calls — one per tool — so failure of one no longer silently suppresses the other.
src/plugins/tools.ts: Adds a log.debug message when a plugin tool factory returns null (guarded to entries that declare at least one name), filling a previously invisible failure path.

Analysis:

The fix is logically correct. Each factory now returns a single tool directly (or null), which is valid per the AnyAgentTool | AnyAgentTool[] | null | undefined type expected by resolvePluginTools.
The entry.names.length > 0 guard in the debug log intentionally keeps anonymous/conditional tool entries silent — only named entries emit the diagnostic.
No behavioral regressions are expected; the tools are independent operations and partial registration (one tool up, one down) is a valid and more resilient state than both-or-nothing.

Confidence Score: 5/5

This PR is safe to merge — the change is minimal, well-targeted, and fixes a real silent-failure bug without introducing new risk.
Both changes are small, focused, and logically sound. The factory split is compatible with the existing resolvePluginTools handling (single-tool returns are wrapped via Array.isArray). The debug log addition is purely additive and guarded correctly. No existing tool registration path is broken.
No files require special attention.

_{Last reviewed commit: "fix(memory-core): re..."}

- azure.md: "What you'll do" -> "What you will do" - standing-orders.md: "Don't" -> "Avoid" Per CLAUDE.md: avoid em dashes and apostrophes in headings because they break Mintlify anchor links.

…ault - cli/plugins.md: rewrite install synopsis with ClawHub-first order - cli/hooks.md: update hook pack install examples - help/troubleshooting.md: <npm-spec> -> <package> - gateway/security/index.md: drop npm-specific framing

…lway docs

Mintlify strips dots from backtick headings when generating anchors. `agents.defaults.sandbox` -> #agentsdefaultssandbox (not #agents-defaults-sandbox)

- sandboxing.md: remove stale '-opt-in' suffix from Docker accordion anchor - troubleshooting.md: remove #troubleshooting anchor (matrix has no such section) - docker.md: drop unpredictable security heading anchor with parens/dots - faq.md: fix SSL error accordion anchor slug

openclaw-barnacle · 2026-03-23T04:50:07Z