Budibase/budibase · error

Error fetching agent log detail: ${text || response.statusTe

Error message

Error fetching agent log detail: ${text || response.statusText}

What it means

fetchLiteLLMRequestSummaryById calls the LiteLLM proxy /requests/{request_id} endpoint and throws this plain Error whenever the HTTP response is not ok and not 404 (404 is translated to a null return). The thrown message embeds the LiteLLM response body if present, otherwise the HTTP status text, so the text usually names the real upstream problem (auth, bad route, proxy down).

Source

Thrown at packages/server/src/sdk/workspace/ai/agentLogs/liteLLM.ts:77

    ),
    page: "1",
    page_size: "1",
  })
  const response = await fetch(
    `${liteLLMUrl}/spend/logs/v2?${params.toString()}`,
    {
      headers: {
        Authorization: liteLLMAuthorizationHeader,
      },
    }
  )

  if (!response.ok) {
    if (response.status === 404) {
      return null
    }
    const text = await response.text()
    throw new Error(
      `Error fetching agent log detail: ${text || response.statusText}`
    )
  }

  const data = (await response.json()) as LiteLLMRequestListResponse | null
  return data?.data?.[0] || null
}

export async function fetchLiteLLMSessionRows(
  sessionId: string
): Promise<{ rows: LiteLLMRequestRecord[]; total: number }> {
  const pageSize = 100
  const rows: LiteLLMRequestRecord[] = []
  let page = 1
  let total = 0
  let totalPages = 1

  while (page <= totalPages) {

View on GitHub (pinned to a81a902e9a)

Solutions

  1. Verify LiteLLM proxy is reachable: curl $AGENT_LITELLM_URL/health and confirm LITELLM_MASTER_KEY / base URL env vars are correct
  2. Check the response body in the error message for the actual LiteLLM error (e.g. invalid API key) and fix credentials
  3. Confirm LiteLLM's Postgres database is up, since /requests queries spend logs stored there
  4. Retry the request if the status was 502/503 indicating a transient proxy outage

Example fix

// before
const text = await response.text()
throw new Error(`Error fetching agent log detail: ${text || response.statusText}`)
// after
const text = await response.text()
console.error(`LiteLLM request summary fetch failed (status ${response.status}): ${text || response.statusText}`)
throw new HTTPError(`Error fetching agent log detail: ${text || response.statusText}`, response.status)
Defensive patterns

Strategy: try-catch

Validate before calling

const base = process.env.AGENT_LITELLM_URL
if (!base) throw new Error("AGENT_LITELLM_URL is not configured")
const health = await fetch(`${base}/health`)
if (!health.ok) throw new Error(`LiteLLM proxy unhealthy: ${health.status}`)

Type guard

function isOkResponse(res: Response): res is Response & { ok: true } {
  return res.ok
}

Try / catch

try {
  const detail = await fetchLiteLLMRequestSummaryById(requestId)
} catch (err) {
  if (err instanceof HTTPError && err.status === 404) return null
  console.error("LiteLLM summary fetch failed", err)
  throw new HTTPError("Agent log detail unavailable", 502)
}

Prevention

When it happens

Trigger: Calling fetchLiteLLMRequestSummaryById (via requestDetail) when LiteLLM returns a non-ok, non-404 status: 401 from a missing/wrong LITELLM_MASTER_KEY or Virtual Key, 500 from LiteLLM's DB (Postgres) being unreachable, 502/503 from the proxy being down or AGENT_LITELLM_URL pointing at the wrong host/port.

Common situations: LiteLLM proxy not running or misconfigured env var for its base URL; expired/rotated LiteLLM API key; LiteLLM's backing Postgres down causing 500s; reverse proxy returning HTML error pages that appear in the message body.

Related errors


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