fix(wiki): register memory publicArtifacts in CLI-metadata mode#70185
fix(wiki): register memory publicArtifacts in CLI-metadata mode#70185prasad-yashdeep wants to merge 1 commit into
Conversation
Greptile SummaryThis PR fixes Confidence Score: 5/5This PR is safe to merge — the fix is narrow, targeted, and consistent with the existing full-registration pattern. Both changes mirror the existing full-registration logic exactly, all 111 tests pass, and no new type errors are introduced. No P0/P1 issues found. No files require special attention. Reviews (1): Last reviewed commit: "fix(wiki): register memory publicArtifac..." | Re-trigger Greptile |
openclaw-barnacle
Bot
added
extensions: memory-core
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d030bbf985
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
`openclaw wiki bridge import` calls `listActiveMemoryPublicArtifacts` to discover memory files across workspaces, but the CLI process only loads plugin `cli-metadata.ts` entries — not the full `index.ts`. The memory-core `cli-metadata.ts` only registered CLI commands and never called `registerMemoryCapability`, so `memoryPluginState.capability` stayed empty and bridge import always returned 0 artifacts. Changes: 1. **`extensions/memory-core/cli-metadata.ts`**: Register the `publicArtifacts` provider (via `listMemoryCorePublicArtifacts`) and declare `kind: "memory"` so the memory slot resolution accepts it. 2. **`src/plugins/loader.ts`**: Wire `registerMemoryCapability` in the CLI-metadata `buildPluginApi` handlers with the same `hasKind` and dual-kind `memorySlotSelected` guards used in full registration. Also snapshot/restore memory plugin state on register failure so a throwing plugin cannot leak a partially-registered capability. Fixes openclaw#70181
d030bbf to
7d1358c
Compare
|
cant wait for this to be fixed, my agents memory is messed up until wiki can work properly |
3 participants
Problem
openclaw wiki bridge importalways returns 0 artifacts / 0 workspaces and destructively removes previously-synced bridge sources — even though the in-process runtime bridge works perfectly with 155+ artifacts.Root cause
The CLI process loads plugin
cli-metadata.tsentries (lightweight) instead of the fullindex.ts. The memory-corecli-metadata.tsonly registered CLI commands and never calledregisterMemoryCapability(), somemoryPluginState.capabilitystayed empty. When the wiki bridge calledlistActiveMemoryPublicArtifacts(), it got nothing back.Additionally, the CLI-metadata plugin loader in
loader.tsonly wiredregisterClias a handler —registerMemoryCapabilitydefaulted to a no-op, so even if the plugin tried to register, it would be silently swallowed.Fix
Two changes:
extensions/memory-core/cli-metadata.ts: Register thepublicArtifactsprovider (vialistMemoryCorePublicArtifacts) and declarekind: "memory"so the memory slot resolution accepts it.src/plugins/loader.ts: WireregisterMemoryCapabilityin the CLI-metadatabuildPluginApihandlers (with the samehasKindguard used in full registration) so the call actually reachesmemoryPluginState.Testing
bridge.test.tstests pass ✅loader.test.tstests pass ✅pi-embedded-runnerare unrelated)Fixes #70181