openclaw - ✅(Solved) Fix [Feature]: stable public SDK path for embedding provider API (independent of memory-core) [1 pull requests, 1 comments, 2 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#74900Fetched 2026-05-01 05:40:11
View on GitHub
Comments
1
Participants
2
Timeline
3
Reactions
2
Timeline (top)
commented ×1cross-referenced ×1labeled ×1

Expose the embedding provider API on a stable plugin-sdk subpath so third-party memory-slot plugins can use it without depending on memory-core internals.

Root Cause

Expose the embedding provider API on a stable plugin-sdk subpath so third-party memory-slot plugins can use it without depending on memory-core internals.

Fix Action

Fix / Workaround

This forces third-party memory-slot plugins into one of two fragile workarounds:

  • Reach into memory-core internals via a non-public path that offers no semver protection, so a memory-core refactor breaks the plugin silently.

  • Reimplement the embedding stack (OpenAI/Gemini factories, batching, input limits, multimodal helpers), which then drifts from the upstream implementation over time.

  • Affected: authors of any third-party plugin that occupies plugins.slots.memory and needs embeddings (custom associative-memory plugins, alternative vector-store backends, experimental memory implementations).

  • Severity: blocks the use case entirely without workarounds; workarounds are either fragile (internal imports) or high-maintenance (reimplementation).

  • Frequency: applies on every embedding call from such a plugin, i.e. every index/search operation.

  • Consequence: ecosystem fragmentation — multiple plugins ship divergent copies of the embedding stack — and silent breakage when memory-core internals change.

PR fix notes

PR #67242: plugin-sdk: add stable embeddings subpath export

Description (problem / solution / changelog)

Summary

  • Problem: when a third-party plugin occupies plugins.slots.memory (e.g. a custom associative-memory plugin), memory-core does not load. With memory-core disabled, the embedding provider API is effectively unavailable through the public SDK — the only path that exposes it today (plugin-sdk/memory-core-host-engine-embeddings) is memory-core-owned, and the embedding registry is empty. Third-party memory-slot plugins are forced to duplicate the embedding implementation (OpenAI/Gemini factories, batching, input limits, multimodal helpers) just to function.
  • Why it matters: without this, any third-party plugin in the memory slot must either (a) reach into memory-core internals via a non-public path that offers no semver protection, or (b) reimplement the embedding stack. Both are fragile: a memory-core refactor breaks silently, and duplicated implementations drift over time.
  • What changed: new stable subpath openclaw/plugin-sdk/embeddings that re-exports the embedding API (factory functions, registry, types, batch helpers) from memory-host-sdk, independent of whether the memory-core extension is active. Bundled extensions (memory-core, ollama) migrated to dogfood the new path and conform to the extension SDK self-import guardrail.
  • What did NOT change: the old internal path keeps working for backward compatibility; memory-core runtime logic is untouched; API baseline hash unchanged (new path re-exports the same symbols).

Change Type (select all)

  • Feature (additive public SDK surface)
  • Bug fix
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

None.

Root Cause (if applicable)

N/A (additive public SDK surface, not a bug fix).

Regression Test Plan (if applicable)

N/A. The repo's existing pnpm plugin-sdk:check-exports and pnpm plugin-sdk:api:check gates lock in the new subpath contract; no new unit test is meaningful for an additive re-export barrel whose API baseline is already verified by these checks.

User-visible / Behavior Changes

None. Existing plugins continue to work unchanged. Plugin authors can switch to the new path when they want stable, documented imports.

Diagram (if applicable)

N/A.

Security Impact (required)

  • New permissions/capabilities? No
  • Secrets/tokens handling changed? No
  • New/changed network calls? No
  • Command/tool execution surface changed? No
  • Data access scope changed? No

Repro + Verification

Environment

  • OS: darwin 24.6.0 (arm64)
  • Runtime/container: Node 22.22.0, pnpm 10.32.1
  • Model/provider: OpenAI text-embedding-3-small
  • Integration/channel: none (CLI-only test bot)
  • Relevant config: plugins.slots.memory = memory-core, OpenAI key in auth-profiles.json

Steps

  1. pnpm build on this branch
  2. pnpm pack → install the tarball into an isolated test directory with OPENCLAW_STATE_DIR pointing at a fresh state dir
  3. openclaw plugins list — confirm memory-core loads
  4. openclaw memory status — confirm embedding provider is ready
  5. openclaw memory index — index a test .md file (triggers the factory call path)
  6. openclaw memory search "marine arthropod lifespan" --min-score 0 — semantic query over a test doc mentioning "crustaceans", "exoskeleton", "live over 50 years"

Expected

  • Memory-core loads through the new openclaw/plugin-sdk/embeddings path without module-resolution errors
  • Indexing issues an embedding request successfully
  • Semantic search returns the matching chunk even without keyword overlap

Actual

  • Memory-core loaded (55 plugins loaded, 0 errors)
  • memory status reported Vector: ready, FTS: ready, provider openai, model text-embedding-3-small
  • memory index produced Memory index updated (main), Indexed: 1/1 files · 1 chunks
  • memory search "marine arthropod lifespan" returned the expected chunk with score 0.17 (no keyword overlap — confirms real vector similarity)

Evidence

  • pnpm tsgo — passes
  • pnpm plugin-sdk:check-exportsplugin-sdk exports synced.
  • pnpm plugin-sdk:api:gen — baseline regenerated, hash unchanged (new path exposes the same symbols as the old one)
  • pnpm build — succeeded, dist/plugin-sdk/embeddings.{js,d.ts} generated
  • Semantic-search log snippet: "score": 0.17198…, "snippet": "… Lobsters are crustaceans with a hard exoskeleton … live over 50 years …"

Human Verification (required)

The PR was deployed and tested with the memory-core plugin on top of 2026.4.14. The build succeeded and the basic memory-core functionality (search) with embeddings worked. openclaw memory status and openclaw memory index also worked.

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

  • Backward compatible? Yes — the old memory-core-host-engine-embeddings path keeps working
  • Config/env changes? No
  • Migration needed? No (third-party plugins can switch to the new path at their own pace)

Risks and Mitigations

  • Risk: SDK surface grows by one subpath.
    • Mitigation: the new subpath is narrow and purpose-built per the src/plugin-sdk/CLAUDE.md boundary rules; it is not a broad convenience barrel.
  • Risk: two paths pointing at the same API may confuse consumers.
    • Mitigation: sdk-overview.md and sdk-migration.md mark the old path with "prefer plugin-sdk/embeddings".

Changed files

  • docs/plugins/sdk-migration.md (modified, +2/-1)
  • docs/plugins/sdk-overview.md (modified, +2/-1)
  • extensions/memory-core/src/memory/embeddings.ts (modified, +2/-2)
  • extensions/memory-core/src/memory/manager-embedding-ops.ts (modified, +1/-1)
  • extensions/memory-core/src/memory/manager-sync-ops.ts (modified, +1/-1)
  • extensions/memory-core/src/memory/provider-adapters.ts (modified, +1/-1)
  • extensions/ollama/src/memory-embedding-adapter.ts (modified, +1/-1)
  • package.json (modified, +4/-0)
  • scripts/lib/plugin-sdk-entrypoints.json (modified, +1/-0)
  • src/plugin-sdk/embeddings.ts (added, +5/-0)
RAW_BUFFERClick to expand / collapse

Summary

Expose the embedding provider API on a stable plugin-sdk subpath so third-party memory-slot plugins can use it without depending on memory-core internals.

Problem to solve

When a third-party plugin occupies plugins.slots.memory (e.g. a custom associative-memory plugin), memory-core does not load. With memory-core disabled, the embedding provider API is effectively unavailable through the public SDK — the only path that exposes it today (plugin-sdk/memory-core-host-engine-embeddings) is memory-core-owned, and the embedding registry is empty when memory-core is not active.

This forces third-party memory-slot plugins into one of two fragile workarounds:

  • Reach into memory-core internals via a non-public path that offers no semver protection, so a memory-core refactor breaks the plugin silently.
  • Reimplement the embedding stack (OpenAI/Gemini factories, batching, input limits, multimodal helpers), which then drifts from the upstream implementation over time.

Neither is sustainable for plugin authors who want to build on the embedding infrastructure without coupling to memory-core's lifecycle.

Proposed solution

Make the embedding provider API available through a stable, documented plugin-sdk subpath that does not depend on whether the memory-core extension is loaded. The exact shape is up to maintainers, but a minimal sketch:

  • A new subpath (e.g. openclaw/plugin-sdk/embeddings) that re-exports the embedding factory functions, registry, types, and batch helpers from memory-host-sdk.
  • Resolution independent of the memory-core extension being active.
  • Old internal path (plugin-sdk/memory-core-host-engine-embeddings) preserved for backward compatibility, marked deprecated in SDK reference docs.

Open to alternative shapes — happy to follow whatever boundary the SDK owners prefer.

Alternatives considered

  • Importing from memory-core-host-engine-embeddings directly: works today but is memory-core-owned and breaks the moment a third-party plugin takes the memory slot.
  • Reimplementing the embedding stack inside each third-party plugin: duplicates non-trivial logic (provider factories, batching, multimodal handling) and drifts from upstream.
  • Reaching into memory-host-sdk internals directly: no semver protection, no documented contract.

Impact

  • Affected: authors of any third-party plugin that occupies plugins.slots.memory and needs embeddings (custom associative-memory plugins, alternative vector-store backends, experimental memory implementations).
  • Severity: blocks the use case entirely without workarounds; workarounds are either fragile (internal imports) or high-maintenance (reimplementation).
  • Frequency: applies on every embedding call from such a plugin, i.e. every index/search operation.
  • Consequence: ecosystem fragmentation — multiple plugins ship divergent copies of the embedding stack — and silent breakage when memory-core internals change.

Evidence/examples

PR #67242 attempted this change and was closed as too broad (crossing memory-core / Ollama / docs / package surfaces) with a request to resubmit as a narrow, owner-backed SDK export change. Opening this issue first to get owner input on shape before any PR work.

Additional information

No response

extent analysis

TL;DR

Expose the embedding provider API through a stable plugin-sdk subpath to allow third-party memory-slot plugins to use it without depending on memory-core internals.

Guidance

  • Create a new subpath (e.g., openclaw/plugin-sdk/embeddings) that re-exports the embedding factory functions, registry, types, and batch helpers from memory-host-sdk.
  • Ensure the new subpath is resolution-independent of the memory-core extension being active.
  • Preserve the old internal path (plugin-sdk/memory-core-host-engine-embeddings) for backward compatibility and mark it as deprecated in SDK reference docs.
  • Consider the impact on third-party plugin authors and the ecosystem as a whole when designing the new subpath.

Example

No code snippet is provided as the issue focuses on the design and implementation of a new subpath rather than a specific code change.

Notes

The proposed solution aims to address the issue of third-party memory-slot plugins being forced into fragile workarounds due to the embedding provider API being tied to memory-core internals. The new subpath should provide a stable and documented way for plugins to access the embedding infrastructure without depending on memory-core's lifecycle.

Recommendation

Apply a workaround by creating a new subpath for the embedding provider API, as this will allow third-party plugins to access the embedding infrastructure without depending on memory-core internals, reducing the risk of ecosystem fragmentation and silent breakage.

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 [Feature]: stable public SDK path for embedding provider API (independent of memory-core) [1 pull requests, 1 comments, 2 participants]