Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Support input_type for asymmetric embeddings in built-in memorySearch [1 pull requests, 1 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#60727•Fetched 2026-04-08 02:47:56
View on GitHub
Comments
0
Participants
1
Timeline
1
Reactions
0
Author
prospect1314521prospect1314521
Participants
prospect1314521prospect1314521
Timeline (top)
cross-referenced ×1

Built-in memorySearch does not currently support passing input_type for OpenAI-compatible embedding providers.

This blocks asymmetric embedding models that require input_type (for example query vs passage).

Root Cause

  • Makes asymmetric embedding usable in built-in memorySearch without manual patches.
  • Avoids upgrade-time regressions for users depending on query/passage semantics.
  • Aligns built-in behavior with plugins that already support this.

Fix Action

Fix / Workaround

Current Behavior

  • memorySearch embedding requests are sent without input_type.
  • Asymmetric models return 400 errors such as: "input_type parameter is required for asymmetric models".
  • Users must patch built dist files again after upgrade.

Why This Matters

  • Makes asymmetric embedding usable in built-in memorySearch without manual patches.
  • Avoids upgrade-time regressions for users depending on query/passage semantics.
  • Aligns built-in behavior with plugins that already support this.

PR fix notes

PR #63313: feat(memory): support asymmetric input types and Ollama batch embeds

Description (problem / solution / changelog)

Summary

Describe the problem and fix in 2–5 bullets:

  • Problem: memory search could not express asymmetric embedding input_type semantics for OpenAI-compatible providers, and Ollama batch indexing still fanned out to sequential /api/embeddings calls.
  • Why it matters: asymmetric retrieval models need different query/document labels for best recall quality, and sequential Ollama embedding calls add avoidable latency and request overhead during indexing.
  • What changed: added memorySearch.inputType, queryInputType, and documentInputType; threaded those values into OpenAI-compatible embedding requests; switched Ollama batch embeddings to /api/embed with compatibility fallback to sequential /api/embeddings.
  • What did NOT change (scope boundary): no memory ranking algorithm, auth surface, or unrelated gateway behavior changed.

AI-assisted: Yes (OpenAI + Sisyphus) Testing level: Fully tested (project-level + targeted tests)

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor
  • 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

  • Closes #60727
  • Closes #45944

User-visible / Behavior Changes

Memory search can now send provider-specific asymmetric embedding labels for query/document flows, and Ollama-backed memory indexing now prefers the batch embed endpoint before falling back to sequential requests.

Security Impact (required)

  • New permissions/capabilities? (No)
  • Secrets/tokens handling changed? (No)
  • New/changed network calls? (Yes)
  • Command/tool execution surface changed? (No)
  • Data access scope changed? (No)
  • If any Yes, explain risk + mitigation:
    • Ollama batch indexing now calls /api/embed on the same configured Ollama base URL before falling back to /api/embeddings.
    • Mitigation: existing remote host / SSRF policy is preserved, and unsupported responses still fall back to the old sequential path.

Repro + Verification

Environment

  • OS: macOS (local dev)
  • Runtime/container: Node 22 + pnpm
  • Model/provider: OpenAI-compatible embeddings + Ollama (nomic-embed-text)
  • Integration/channel (if any): memory search / embedding providers
  • Relevant config (redacted): agents.defaults.memorySearch.{provider,model,inputType,queryInputType,documentInputType}

Steps

  1. Configure memorySearch.provider: openai with asymmetric queryInputType / documentInputType values.
  2. Trigger query embeddings and document/index embeddings.
  3. Verify OpenAI-compatible /embeddings request bodies include the expected input_type value for each flow.
  4. Configure memorySearch.provider: ollama and run batch embedding/indexing.
  5. Verify Ollama batch requests use /api/embed, and unsupported responses fall back to sequential /api/embeddings calls.

Expected

  • Query embeddings use the configured query input_type.
  • Document/index embeddings use the configured document input_type.
  • Ollama batch embedding uses /api/embed when available, with compatibility fallback if not.

Actual

  • Added targeted and full-suite verification confirming the new request semantics and Ollama batch path behavior.

Evidence

Attach at least one:

  • Failing test/log before + passing after
  • Trace/log snippets
  • Screenshot/recording
  • Perf numbers (if relevant)

Added / updated regression coverage:

  • src/agents/memory-search.test.ts
  • src/memory/embeddings.test.ts
  • src/memory/embeddings-ollama.test.ts
  • src/memory/index.test.ts
  • config/schema coverage via:
    • src/config/schema.help.quality.test.ts
    • src/config/config.schema-regressions.test.ts

Human Verification (required)

What you personally verified (not just CI), and how:

  • Verified scenarios:
    • pnpm test -- src/memory/embeddings.test.ts src/memory/embeddings-ollama.test.ts src/agents/memory-search.test.ts src/memory/index.test.ts
    • pnpm test -- src/config/schema.help.quality.test.ts src/config/config.schema-regressions.test.ts
    • pnpm config:docs:gen && pnpm config:docs:check && pnpm check && pnpm build
    • pnpm test
    • manual runtime check that OpenAI-compatible requests emitted query/document-specific input_type values and Ollama batch embeddings hit /api/embed
  • Edge cases checked:
    • blank / missing inputType values do not force request fields
    • queryInputType overrides shared inputType for query embeddings
    • documentInputType overrides shared inputType for document/index embeddings
    • Ollama fallback activates when /api/embed does not return embeddings[]
  • What you did not verify:
    • live remote-provider behavior against every third-party OpenAI-compatible server variant

Compatibility / Migration

  • Backward compatible? (Yes)
  • Config/env changes? (Optional)
  • Migration needed? (No)
  • If yes, exact upgrade steps:
    • Optional: set agents.defaults.memorySearch.inputType, queryInputType, and/or documentInputType when using asymmetric embedding providers.

Failure Recovery (if this breaks)

  • How to disable/revert this change quickly: revert this PR commit series.
  • Files/config to restore: memory embedding provider files and the new memorySearch config fields.
  • Known bad symptoms reviewers should watch for: missing embeddings from unsupported OpenAI-compatible input_type values, or unexpected Ollama batch failures before fallback.

Risks and Mitigations

  • Risk: some OpenAI-compatible embedding backends may reject custom input_type values.
    • Mitigation: fields are opt-in and omitted unless explicitly configured.
  • Risk: some Ollama deployments may not support /api/embed response shape.
    • Mitigation: unsupported responses fall back to the previous sequential /api/embeddings behavior.

Changed files

  • extensions/memory-core/src/memory/index.test.ts (modified, +46/-1)
  • extensions/memory-core/src/memory/manager-provider-state.ts (modified, +12/-0)
  • extensions/memory-core/src/memory/manager.mistral-provider.test.ts (modified, +15/-0)
  • extensions/memory-core/src/memory/provider-adapters.ts (modified, +3/-0)
  • extensions/memory-wiki/index.test.ts (modified, +3/-0)
  • extensions/ollama/src/embedding-provider.test.ts (added, +69/-0)
  • extensions/ollama/src/embedding-provider.ts (modified, +34/-0)
  • src/agents/memory-search.test.ts (modified, +27/-0)
  • src/agents/memory-search.ts (modified, +11/-0)
  • src/config/schema.base.generated.ts (modified, +48/-0)
  • src/config/schema.help.ts (modified, +6/-0)
  • src/config/schema.labels.ts (modified, +3/-0)
  • src/config/types.tools.ts (modified, +3/-0)
  • src/config/zod-schema.agent-runtime.ts (modified, +3/-0)
  • src/infra/outbound/target-resolver.test.ts (modified, +8/-0)
  • src/memory-host-sdk/host/embeddings-openai.ts (modified, +52/-10)
  • src/memory-host-sdk/host/embeddings.test.ts (modified, +43/-0)
  • src/memory-host-sdk/host/embeddings.types.ts (modified, +3/-0)
  • src/plugins/contracts/boundary-invariants.test.ts (modified, +1/-0)
  • test/extension-test-boundary.test.ts (modified, +1/-0)
  • test/helpers/plugins/public-artifacts.ts (modified, +1/-0)
RAW_BUFFERClick to expand / collapse

Summary

Built-in memorySearch does not currently support passing input_type for OpenAI-compatible embedding providers.

This blocks asymmetric embedding models that require input_type (for example query vs passage).

Current Behavior

  • memorySearch embedding requests are sent without input_type.
  • Asymmetric models return 400 errors such as: "input_type parameter is required for asymmetric models".
  • Users must patch built dist files again after upgrade.

Expected Behavior

Add official config support in gents.defaults.memorySearch and forward it to embedding request body:

  • inputType (optional global default)
  • queryInputType (optional)
  • documentInputType (optional)

Suggested Config Example (generic)

json "memorySearch": { "enabled": true, "provider": "openai", "remote": { "baseUrl": "https://api.example.com/v1", "apiKey": "***" }, "model": "your-asymmetric-embedding-model", "queryInputType": "query", "documentInputType": "passage" }

Why This Matters

  • Makes asymmetric embedding usable in built-in memorySearch without manual patches.
  • Avoids upgrade-time regressions for users depending on query/passage semantics.
  • Aligns built-in behavior with plugins that already support this.

extent analysis

TL;DR

Add official configuration support for input_type in memorySearch to enable asymmetric embedding models.

Guidance

  • Modify the agents.defaults.memorySearch configuration to include optional inputType, queryInputType, and documentInputType parameters.
  • Update the embedding request body to forward the configured input_type.
  • Use the suggested config example as a template to set up asymmetric embedding models, such as setting queryInputType toquery and documentInputType to "passage".
  • Verify that the 400 errors are resolved and asymmetric models function as expected after applying the configuration changes.

Example

"memorySearch": {
  "enabled": true,
  "provider": "openai",
  "remote": { "baseUrl": "https://api.example.com/v1", "apiKey": "***" },
  "model": "your-asymmetric-embedding-model",
  "queryInputType": "query",
  "documentInputType": "passage"
}

Notes

This solution assumes that the embedding provider supports the input_type parameter and that the model requires it. The exact configuration and embedding request body updates may vary depending on the specific use case and provider.

Recommendation

Apply workaround by adding the suggested configuration support for input_type in memorySearch, as this will enable asymmetric embedding models without requiring manual patches or upgrades.

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…
#api#API rate limit#retriever error#indexing error#inference speed

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING