Budibase/budibase · warning · HTTPError

Agent log details not ready

Error message

Agent log details not ready

What it means

addSessionLog builds an indexed agent-log session record from LiteLLM request data. It first collects distinct request_ids for the session; if none are found (no matching LiteLLM requests yet), it throws an HTTPError 404 'Agent log details not ready' because the details needed to index the session do not exist.

Source

Thrown at packages/server/src/sdk/workspace/ai/agentLogs/indexQueue.ts:108

  input: IndexAgentLogOperationInput
): Promise<void> {
  if (!input.agentId || !input.sessionId) {
    return
  }

  let uniqueRequestIds = [...new Set(input.requestIds)].filter(Boolean)
  if (!uniqueRequestIds.length) {
    const { rows } = await fetchLiteLLMSessionRows(input.sessionId)
    uniqueRequestIds = rows
      .filter(
        row => getLiteLLMRequestUser(row) === getExpectedEndUser(input.agentId)
      )
      .map(row => row.request_id)
      .filter((requestId): requestId is string => !!requestId)
  }

  if (!uniqueRequestIds.length) {
    throw new HTTPError("Agent log details not ready", 404)
  }

  const db = context.getWorkspaceDB()
  const trigger = determineTrigger(input.sessionId)
  const isPreview = isPreviewSession(input.sessionId)
  const firstInput = truncateText(input.firstInput || "")
  const fallbackStartTime = parseDateOrThrow(input.startedAt, "startedAt")
  const fallbackEndTime = parseDateOrThrow(input.completedAt, "completedAt")

  const summaryResults = await Promise.all(
    uniqueRequestIds.map(async requestId => {
      try {
        const requestDetail = await fetchLiteLLMRequestSummaryById(
          requestId,
          fallbackStartTime,
          fallbackEndTime
        )
        if (!requestDetail) {

View on GitHub (pinned to a81a902e9a)

Solutions

1. Retry after a short delay so LiteLLM has time to persist the request records.
2. Verify the sessionId used matches the one passed to LiteLLM during the agent run.
3. Check LITELLM_URL / LITELLM_MASTER_KEY config so the query is hitting the right LiteLLM instance with data.
4. If the session genuinely never ran, discard the queued log entry rather than retrying.

Example fix

// before
await addSessionLog({ sessionId: input.sessionId, ... })
// after
if (!(await sessionHasRequests(input.sessionId))) return // skip not-ready sessions
await addSessionLog({ sessionId: input.sessionId, ... })

const requestIds = await fetchLiteLLMRequestIds(sessionId)
if (!requestIds.length) return // not ready yet; skip instead of throwing

const hasRequests = (ids: (string | undefined)[]): ids is string[] => ids.length > 0

try {
  await addSessionLog(input)
} catch (e) {
  if (e instanceof HTTPError && e.status === 404) {
    await requeueWithDelay(input) // LiteLLM details may arrive later
  } else {
    throw e
  }
}

When it happens

Trigger: Calling addSessionLog (during agent log queue init/processing) for a sessionId whose LiteLLM requests have not been recorded yet - empty or unflushed LiteLLM logs, or a sessionId mismatch with LiteLLM request metadata.

Common situations: Querying agent logs immediately after an agent run before LiteLLM persisted its request rows; a stale sessionId from a failed/aborted run; clock/log-ingestion lag between the agent run and LiteLLM storage.

Related errors

• Error getting account by tenantId ${tenantId}
• Streaming not supported in this browser
• Error generating tables
• No result received from table generation stream
• LLM not available

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