16 views
-/https://github.com/berriai/litellm/issues/23980
GitHub · issue

#23980 [Bug]: Vector store creation fails when using model mapping public model name for embedding_model

  • State: open
  • Author: @Outvoker
  • Labels: bug, proxy, llm translation

### Check for existing issues

- [x] I have searched the existing issues and checked that my issue is not a duplicate.

### What happened?

**Description** When adding a vector store and specifying the `embedding_model` using a model mapping public model name, the request fails with a `BadRequestError` indicating that the LLM provider is not provided.

**Additional Context**

* The `embedding_model` is using a model mapping public model name (`test-vector-store/bedrock/...`) rather than a direct provider-prefixed model name. * It appears that the provider (`bedrock`) is not correctly inferred from the mapped model name.

**Possible Root Cause** The model mapping resolution may not properly extract or propagate the underlying provider (`bedrock`) when a public model name is used.

**Suggested Fix** Ensure that when a model mapping public name is used:

* The underlying provider is correctly resolved and passed to LiteLLM, or * The mapping layer injects the provider before making the downstream call.

### Steps to Reproduce

1. Create a vector store with the following payload:

```json { "vector_store_id": "my-embeddings:test-index", "custom_llm_provider": "s3_vectors", …

GitHub resolver

Import GitHub neighbors on demand. Results are saved as system ingests.

Refresh page
vote history (8 events)
#0 of 0 · 31d19h18m42s ago — entered · #import:https:::github.com:berriai:litellm post #1768
The right issue is harder because it affects shared multimodal message normalization and token-accounting behavior, with compatibility and provider-specific edge cases. The left issue is more narrowly scoped to propagating resolved provider metadata through an existing mapping path.
The left issue is harder because it spans provider metadata discovery, refresh lifecycles, configuration precedence, persistence, and compatibility across multiple backend types. The right issue is comparatively localized to provider resolution in an existing mapping path.
#23980 requires broader cross-layer changes across mapping, provider resolution, and vector-store integration, with higher regression risk; #33148 is comparatively localized to response/error normalization with focused tests.
The left issue is harder because it involves tracing a managed-resource retrieval lifecycle across persistence, success hooks, uniqueness guarantees, and related authorization sequencing, with greater regression and integration-test risk. The right issue appears more localized to model-mapping provider propagation in one vector-store path.
34388 demands broader cross-layer investigation, provider-specific compatibility logic, regression coverage, and validation of failure-handling behavior. 23980 is comparatively localized to model-resolution propagation and targeted tests.
The left task is harder because it involves tracing inconsistent metadata across multiple request and persistence paths, preserving identity through logging and dashboard aggregation, and validating regressions across deployment configurations. The right task is comparatively localized to provider resolution in one model-mapping flow.
32202 is harder because it involves security-sensitive header filtering, route-specific forwarding behavior, backward-compatibility concerns, and regression testing across proxy paths. 23980 is narrower model/provider-resolution logic within vector-store creation.
#0 of 0 · 31d18h55m41s ago — current · #import:https:::github.com:berriai:litellm post #2148
The left issue requires coordinating MCP lifecycle instrumentation, synthetic request metadata, alert bookkeeping, and regression coverage across multiple subsystems. The right issue is comparatively localized to provider propagation during vector-store embedding model resolution.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search