feat(memory-core): consume generic embedding providers#84991
Conversation
|
Codex review: needs changes before merge. Workflow note: Future ClawSweeper reviews update this same comment in place. How this review workflow works
Summary Reproducibility: yes. for the review finding by source inspection: current main retries PR rating Rank-up moves:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. Real behavior proof Risk before merge
Maintainer options:
Copy recommended automerge instructionNext step before merge Security Review findings
Review detailsBest possible solution: Settle #84947, preserve custom provider alias semantics for generic lookup and fallback model resolution, then merge the bridge with equivalent Testbox/temp-plugin proof and explicit credential-boundary approval. Do we have a high-confidence way to reproduce the issue? Yes for the review finding by source inspection: current main retries Is this the best way to solve the issue? No, not as currently written. The generic bridge is the right direction, but it should preserve the existing custom provider alias contract and wait for the stacked base embedding-provider contract to settle. Label justifications:
Full review comments:
Overall correctness: patch is incorrect Acceptance criteria:
What I checked:
Likely related people:
Codex review notes: model gpt-5.5, reasoning high; reviewed against 7f4bd454febf. |
|
ClawSweeper PR egg 🔥 Warming up: real-behavior proof passed; findings, security review, or rank-up moves are still in progress. Hatch commandComment Hatchability rules:
What is this egg doing here?
|
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
|
@clawsweeper re-review |
17d00ae to
a1e7a40
Compare
a574850 to
3e858f0
Compare
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
a1e7a40 to
e453696
Compare
3e858f0 to
bfa2494
Compare
|
Closing this as superseded by #85269, which landed the generic embedding provider bridge directly in core. #85269 includes the memory-core generic provider consumption, runtime lookup, docs, and focused bridge/integration tests that this stacked PR was carrying, then merged as 4d89e00. No follow-up is needed on this branch; remaining cleanup should continue in the deprecation PR #85072. |
Summary
embeddingProviderscontract added in feat(plugins): add embedding provider contract #84947.autoselection behavior, so generic providers are opt-in for memory until configured explicitly.contracts.embeddingProviders, registers a generic provider through the real plugin API, and is consumed by memory-core through explicit config.Stacked on #84947 via
mbelinky/84947-general-embedding-providers-base.Verification
Behavior addressed: memory-core can consume a generic embedding provider by explicit provider id without changing memory auto-selection or overriding memory-specific providers.
Real environment tested: Blacksmith Testbox through Crabbox on Linux for both the focused test gate and a non-test temporary plugin/config proof. Provider:
blacksmith-testbox. Proof ids:tbx_01ks5qfqmvttp0prg28e7p01ng(focused gate, Actions run https://github.com/openclaw/openclaw/actions/runs/26240537485) andtbx_01ks5s24ra7bcez8891q9050b3(non-test temp plugin proof, Actions run https://github.com/openclaw/openclaw/actions/runs/26241975310). No live third-party endpoint was called in this PR.Exact steps or command run after this patch: ran the focused Testbox gate for
extensions/memory-core/src/memory/generic-embedding-provider.bridge.test.ts,extensions/memory-core/src/memory/embeddings.test.ts,src/plugins/contracts/embedding-provider.contract.test.ts, andsrc/plugins/embedding-provider-runtime.test.ts, plus extension test typecheck, oxlint, oxfmt, andgit diff --check. Then ran a non-testnode --import tsxproof that created a temporary plugin directory containingpackage.json,openclaw.plugin.json, andindex.cjs, configuredplugins.load.pathsto that plugin root, declaredcontracts.embeddingProviders: ["proof-memory-generic"], registeredapi.registerEmbeddingProvider(...), and called memory-corecreateEmbeddingProvider(...)withprovider: "proof-memory-generic".Evidence after fix from the non-test proof:
{ "pluginRoot": "<temp>/proof-memory-generic", "manifestContracts": [ "proof-memory-generic" ], "configuredLoadPaths": [ "<temp>/proof-memory-generic" ], "globalGenericProvidersAfterColdLoad": [], "globalMemoryProvidersAfterColdLoad": [], "requestedProvider": "proof-memory-generic", "provider": { "id": "proof-memory-generic", "model": "proof-model", "maxInputTokens": 128 }, "runtime": { "id": "proof-memory-generic", "cacheKeyData": { "provider": "proof-memory-generic", "model": "proof-model", "dimensions": 2 }, "inlineQueryTimeoutMs": 111, "inlineBatchTimeoutMs": 222 }, "query": [ 10, 1 ], "batch": [ [ 5, 0 ], [ 5, 1 ] ], "structured": [ [ 5, 0 ] ] }Observed result after fix: a manifest-owned generic embedding provider from a temporary plugin/config path is resolved by memory-core for explicit provider requests, maps
outputDimensionalityto genericdimensions, preserves runtime metadata, routes query calls as query embeddings, routes document batch and structured inputs as document embeddings, and does not register or rely on memory-specific providers. The focused Testbox gate also passed 4 Vitest files / 15 tests covering the virtual-plugin bridge, memory-core adapter behavior, generic embedding provider contract tests, and runtime lookup tests.What was not tested: no live third-party embedding endpoint was called here; that belongs to the follow-up OpenAI-compatible generic provider PR.