What causes "Gemini file store creation did not return an id" in Budibase/budibase?

Verify LITELLM_URL points at a LiteLLM version supporting POST /v1/vector_stores with {id} in the response

Budibase/budibase · error · HTTPError

Gemini file store creation did not return an id

Error message

Gemini file store creation did not return an id

What it means

createGeminiFileStore POSTs to LiteLLM to create a Gemini vector store. After a successful (ok) response, it parses the JSON and expects an `id` field; if the payload has no id, HTTPError 500 is thrown because the store cannot be referenced later. This indicates an unexpected response shape from the proxy.

Source

Thrown at packages/server/src/sdk/workspace/ai/knowledgeBase/geminiFileStore.ts:163

  const geminiApiKey = getGeminiApiKey()
  const response = await fetch(`${environment.LITELLM_URL}/v1/vector_stores`, {
    method: "POST",
    headers: await getCommonAuthHeaders(),
    body: JSON.stringify({
      name,
      custom_llm_provider: "gemini",
      ...(geminiApiKey ? { api_key: geminiApiKey } : {}),
    }),
  })

  await handleNotOkResponse({
    response,
    fallbackMessage: "Failed to create Gemini file store",
  })

  const payload = (await response.json()) as CreateVectorStoreResponse
  if (!payload.id) {
    throw new HTTPError("Gemini file store creation did not return an id", 500)
  }

  return payload.id
}

export async function deleteGeminiVectorStore(
  vectorStoreId: string
): Promise<void> {
  const geminiApiKey = getGeminiApiKey()
  const response = await requestWithRetries(async () =>
    fetch(
      `${environment.LITELLM_URL}/v1/vector_stores/${encodeURIComponent(vectorStoreId)}`,
      {
        method: "DELETE",
        headers: await getCommonAuthHeaders(),
        body: JSON.stringify({
          custom_llm_provider: "gemini",
          ...(geminiApiKey ? { api_key: geminiApiKey } : {}),

View on GitHub (pinned to a81a902e9a)

Solutions

Verify LITELLM_URL points at a LiteLLM version supporting POST /v1/vector_stores with {id} in the response
Log the raw response body to inspect the actual payload shape
Upgrade LiteLLM or align the proxy to the expected OpenAI vector-stores response format
Retry the creation — a transient proxy fault can return an empty 2xx

Example fix

null

Defensive patterns

Strategy: try-catch

Type guard

const hasStoreId = (p: unknown): p is { id: string } =>
  typeof p === "object" && p !== null && "id" in p && typeof (p as { id: unknown }).id === "string"

Try / catch

try {
  const storeId = await createGeminiFileStore(name)
} catch (e) {
  if (e instanceof HTTPError && e.status === 500 && e.message.includes("did not return an id")) {
    // inspect LiteLLM version/response shape, retry or upgrade proxy
  }
}

Prevention

Pin/verify a LiteLLM version that returns { id } from POST /v1/vector_stores
Log raw responses from the vector_stores endpoint during integration tests
Beware reverse proxies that swallow bodies and return 2xx

When it happens

Trigger: The vector_stores endpoint returns 200 with a body lacking `id` — e.g. LiteLLM version that returns a different envelope (id nested elsewhere or named differently), or a proxy/gateway returning a 2xx with an empty or HTML body.

Common situations: Outdated or non-standard LiteLLM proxy behind LITELLM_URL that doesn't implement the OpenAI-compatible vector_stores API; a reverse proxy (nginx) returning 200 with an error page; LiteLLM version drift after upgrade.

Related errors

AI-assisted analysis of Budibase/budibase@a81a902e9a (2026-08-29). Data as JSON: /api/errors/435ccbb8b6ff5045. Report an issue: GitHub.