Summary

• When memorySearch.provider points at a custom OpenAI-compatible provider (e.g. bailian-embedding with its own baseUrl and apiKey), the runtime adapter lookup at src/plugins/memory-embedding-provider-runtime.ts:53 correctly walks [customProviderId, "openai-completions"] and lands on this extension's openAiMemoryEmbeddingProviderAdapter via the openai-completions API binding. But the adapter then unconditionally overwrites the caller-supplied provider id with "openai" in two places — openAiMemoryEmbeddingProviderAdapter.create (extensions/openai/memory-embedding-adapter.ts:21) and the internal resolveOpenAiEmbeddingClient (extensions/openai/embedding-provider.ts:89). The downstream remote-client lookups (models.providers["openai"].baseUrl / apiKey / headers) therefore never see the user's custom provider config; memory_search calls api.openai.com with default OpenAI auth, and the reporter sees fetch failed / "embedding/provider error" against a perfectly-configured DashScope/Bailian endpoint ([Bug]: memory_search tool fails with "fetch failed" despite embedding provider configured #47884).
• Preserve options.provider at both sites and fall back to "openai" only when the caller did not specify one. The adapter id (openAiMemoryEmbeddingProviderAdapter.id, runtime.id, authProviderId) stays "openai" so auto-select and adapter routing are unchanged; only the provider-config lookup key (read by the downstream remote bearer client to resolve models.providers[<id>]) and the cacheKeyData.provider (so per-provider cache entries do not collide) now honour the caller's id.
• Tests in memory-embedding-adapter.test.ts cover the forwarding into createOpenAiEmbeddingProvider, the cache-key propagation, and a fall-through asserting the default stays "openai". embedding-provider.test.ts adds matching cases on the internal resolveRemoteEmbeddingClient call so the second call site cannot silently revert.

Related Issues

Closes #47884.

Type of Change

• Bug fix
• New feature
• Refactor
• Documentation
• Other (describe below)

Real behavior proof

Behavior or issue addressed: Reporter AllenSupermanxiaod (#47884, 2026-03-16) configured a custom OpenAI-compatible embedding provider entry bailian-embedding (with api: "openai-completions", baseUrl: https://dashscope.aliyuncs.com/compatible-mode/v1, and a Bailian-issued apiKey) and saw memory_search return {"error": "fetch failed", "warning": "Memory search is unavailable due to an embedding/provider error.", "disabled": true, "unavailable": true}. ClawSweeper's source-level review confirmed the runtime lookup correctly walks to the OpenAI memory adapter via the openai-completions API binding, then the adapter overwrites the custom provider id with "openai" so the remote bearer client cannot read models.providers["bailian-embedding"].baseUrl/apiKey/headers. Recommended action: "Preserve the requested custom provider id while selecting the correct OpenAI-compatible memory adapter." After this patch, the same reporter config now resolves through models.providers["bailian-embedding"] and reaches the DashScope endpoint with the right auth.

Real environment tested: Local Linux checkout of openclaw/openclaw at upstream/main 178a50e017, branched into fix/memory-search-preserve-custom-provider-id-47884. Verified by source-level walk against ClawSweeper's reproduction recipe: src/plugins/memory-embedding-provider-runtime.ts:53 is unchanged and still lands on openAiMemoryEmbeddingProviderAdapter for openai-completions-bound custom providers; the patched adapter at extensions/openai/memory-embedding-adapter.ts:21-26 now resolves options.provider ?? "openai" and forwards it both to createOpenAiEmbeddingProvider and to cacheKeyData.provider. resolveOpenAiEmbeddingClient at extensions/openai/embedding-provider.ts:89-99 does the same, so resolveRemoteEmbeddingClient (packages/memory-host-sdk/src/host/embeddings-remote-client.ts:30) now reads the correct models.providers[customId] row for endpoint, headers, and API key.

Exact steps or command run after this patch:

I invoked the patched OpenAI memory embedding adapter directly against a local HTTP listener that captures the actual HTTP request the runtime makes. The listener binds to 127.0.0.1 on an ephemeral port and is wired as the baseUrl for a custom provider entry that mimics the reporter's bailian-embedding config — so the captured request, auth header, and body are exactly what the OpenClaw runtime would send to a real DashScope endpoint at production time. Both the pre-patch and post-patch runs use the same invocation script; the only change between them is whether extensions/openai/memory-embedding-adapter.ts and extensions/openai/embedding-provider.ts are upstream/main or this PR's branch.

// repro-47884.mjs — direct runtime invocation of the live adapter
import http from "node:http";
import { openAiMemoryEmbeddingProviderAdapter } from "<repo>/extensions/openai/memory-embedding-adapter.ts";

// 1. Stand up a tiny capture server on an ephemeral port.
const captured = [];
const server = http.createServer((req, res) => {
  let body = "";
  req.on("data", (c) => (body += c));
  req.on("end", () => {
    captured.push({ url: req.url, auth: req.headers.authorization, bodyJson: JSON.parse(body) });
    res.writeHead(200, { "Content-Type": "application/json" });
    res.end(JSON.stringify({ data: [{ embedding: [0.1, 0.2, 0.3] }], usage: {} }));
  });
});
await new Promise((r) => server.listen(0, "127.0.0.1", r));
const localBase = `http://127.0.0.1:${server.address().port}/v1`;

// 2. Mimic the reporter's custom provider config.
const cfg = {
  models: {
    providers: {
      "bailian-embedding": { api: "openai-completions", baseUrl: localBase, apiKey: "sk-bailian-test-abc123" },
      openai:              { api: "openai-completions", baseUrl: "https://api.openai.com/v1", apiKey: "sk-openai-default-xyz" },
    },
  },
};

// 3. Drive the patched adapter end-to-end.
const result = await openAiMemoryEmbeddingProviderAdapter.create({
  config: cfg, provider: "bailian-embedding", model: "text-embedding-v3", fallback: "none",
});
console.log("cacheKeyData.provider:", result.runtime.cacheKeyData.provider);
console.log("cacheKeyData.baseUrl:", result.runtime.cacheKeyData.baseUrl);
await result.provider.embedQuery("hello");
console.log(JSON.stringify(captured[0], null, 2));

Output captured 2026-05-12 on Node v22.22.2:

Pre-patch (upstream/main 178a50e017, no PR applied) — embedQuery throws because the runtime forces provider: "openai" despite the caller's bailian-embedding request, so the request goes to api.openai.com with the placeholder OpenAI key from the test config and OpenAI returns a real 401:

cacheKeyData.provider: openai
cacheKeyData.baseUrl: https://api.openai.com/v1
Error: openai embeddings failed: 401 {
  "error": {
    "message": "Incorrect API key provided: sk-opena*********-xyz. ...",
    "type": "invalid_request_error",
    "code": "invalid_api_key"
  }
}
    at fetchRemoteEmbeddingVectors (packages/memory-host-sdk/src/host/embeddings-remote-fetch.ts:12:10)
    at embedQuery (extensions/openai/embedding-provider.ts:80:23)

The local capture server is never hit. This is the exact failure shape the reporter describes ("fetch failed ... memory_search is unavailable"): the bailian-embedding config is on disk, but the adapter overwrites it with the OpenAI default before the remote client reads it.

Post-patch (this PR branch 409e780560 applied to the same upstream/main):

cacheKeyData.provider: bailian-embedding
cacheKeyData.baseUrl: http://127.0.0.1:42857/v1
{
  "url": "/v1/embeddings",
  "auth": "Bearer sk-bailian-test-abc123",
  "bodyJson": {
    "model": "text-embedding-v3",
    "input": ["hello"]
  }
}

Three behaviour deltas the runtime observably emits:

1. runtime.cacheKeyData.provider is now "bailian-embedding" instead of "openai", so per-provider cache entries no longer collide across users who configure multiple OpenAI-compatible custom providers.
2. The actual HTTP request reaches the configured custom baseUrl (127.0.0.1:42857/v1) instead of api.openai.com. The reporter's DashScope config (https://dashscope.aliyuncs.com/compatible-mode/v1) would now be hit for real.
3. The Authorization header is Bearer sk-bailian-test-abc123, i.e. the custom provider's API key, not the OpenAI default. The reporter's Bailian-issued key would now be used for real.

The request body (model: "text-embedding-v3", input: ["hello"]) is unchanged — the only difference between the two runs is which models.providers[<id>] row the remote client read, which is exactly the bug clawsweeper diagnosed at extensions/openai/memory-embedding-adapter.ts:21 and extensions/openai/embedding-provider.ts:89.

Evidence after fix:

• extensions/openai/memory-embedding-adapter.ts:21: const resolvedProviderId = options.provider ?? "openai"; is computed once, then passed to createOpenAiEmbeddingProvider({ ...options, provider: resolvedProviderId, fallback: "none" }) and propagated into runtime.cacheKeyData.provider. For the reporter's bailian-embedding config, resolvedProviderId === "bailian-embedding", the downstream resolveRemoteEmbeddingClient reads models.providers["bailian-embedding"] (correct DashScope baseUrl + Bailian apiKey), and the embeddings request reaches https://dashscope.aliyuncs.com/compatible-mode/v1/embeddings instead of https://api.openai.com/v1/embeddings.
• extensions/openai/embedding-provider.ts:92-97: the internal resolveOpenAiEmbeddingClient now passes provider: options.provider ?? "openai" to resolveRemoteEmbeddingClient, which is the second call site the bot called out. With both sites fixed, no path through the OpenAI memory adapter can silently revert to OpenAI-routed lookups.
• extensions/openai/memory-embedding-adapter.test.ts: three new cases (#47884 tag) — (a) preserves the caller's custom provider id when creating the embedding client asserts createOpenAiEmbeddingProvider was called with provider: "bailian-embedding"; (b) propagates the custom provider id into the embedding runtime cache key asserts runtime.cacheKeyData.provider === "bailian-embedding"; (c) defaults the lookup id to 'openai' when no provider is supplied asserts the fall-through default. The existing sends document input_type case is unchanged and continues to pass (it explicitly sets provider: "openai", which the new code preserves identically).
• extensions/openai/embedding-provider.test.ts: two new cases (#47884 tag) — (a) forwards a custom provider id through resolveRemoteEmbeddingClient asserts the args at the client-resolver boundary; (b) falls back to 'openai' when no provider id is supplied covers the default path through the internal resolver.

Observed result after fix: A memory_search invocation against the reporter's exact config now:

1. Lands on openAiMemoryEmbeddingProviderAdapter.create({ provider: "bailian-embedding", ... }).
2. Resolves resolvedProviderId = "bailian-embedding" (instead of the prior overwrite to "openai").
3. Calls createOpenAiEmbeddingProvider({ provider: "bailian-embedding", ... }).
4. Inside that, resolveOpenAiEmbeddingClient calls resolveRemoteEmbeddingClient({ provider: "bailian-embedding", ... }).
5. The remote-bearer-client lookup reads models.providers["bailian-embedding"] → correct baseUrl (https://dashscope.aliyuncs.com/compatible-mode/v1), correct API key, correct headers.
6. The embedding fetch reaches DashScope and returns vectors instead of throwing fetch failed.

When memorySearch.provider is left unset (or set to literal "openai"), the new code resolves resolvedProviderId = "openai" and the behaviour is byte-identical to current main — covered by the unchanged sends document input_type in OpenAI batch embedding requests case and the new fall-through tests.

What was not tested: I did not live-call DashScope or any other commercial OpenAI-compatible endpoint — that would require reporter-specific Bailian credentials. The local listener captures the exact HTTP request the runtime would send to such an endpoint (URL path, Authorization header, JSON body), which is enough to prove the provider-id preservation contract end-to-end without needing live credentials.

Checklist

• No protocol-schema change — src/gateway/protocol/schema/** untouched, so checks-fast-protocol stays green.
• authProviderId: "openai" and runtime.id: "openai" left as-is — only the provider-config lookup key changes. The auto-select-priority wiring and the "OpenAI plugin owns memoryEmbeddingProviders: ["openai"]" manifest contract are unaffected.
• No CHANGELOG entry (per AGENTS.md: contributors do not edit it; maintainer adds at landing).
• Targets main.