Budibase/budibase · error

Invalid LiteLLM date: ${value}

Error message

Invalid LiteLLM date: ${value}

What it means

getLiteLLMDayBoundary converts a user-supplied date string into a UTC day boundary (start 00:00:00.000 or end 23:59:59.999) for LiteLLM log queries. parseDate must produce a valid date; otherwise the input is rejected with 'Invalid LiteLLM date: <value>'.

Source

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

function formatLiteLLMDateTime(date: Date): string {
  const pad = (part: number) => String(part).padStart(2, "0")
  return (
    [
      date.getUTCFullYear(),
      pad(date.getUTCMonth() + 1),
      pad(date.getUTCDate()),
    ].join("-") +
    ` ${pad(date.getUTCHours())}:${pad(date.getUTCMinutes())}:${pad(
      date.getUTCSeconds()
    )}`
  )
}

function getLiteLLMDayBoundary(value: string, mode: "start" | "end"): string {
  const parsedDate = parseDate(value)
  if (!parsedDate) {
    throw new Error(`Invalid LiteLLM date: ${value}`)
  }

  const boundary = new Date(parsedDate)
  if (mode === "start") {
    boundary.setUTCHours(0, 0, 0, 0)
  } else {
    boundary.setUTCHours(23, 59, 59, 999)
  }

  return formatLiteLLMDateTime(boundary)
}

export async function fetchLiteLLMRequestSummaryById(
  requestId: string,
  startDate?: string,
  endDate?: string
): Promise<LiteLLMRequestDetail | null> {
  const params = new URLSearchParams({

View on GitHub (pinned to a81a902e9a)

Solutions

  1. Send dates in an ISO 8601 format the parser supports, e.g. 2026-08-28 or 2026-08-28T10:00:00Z.
  2. Validate/parse dates on the client before issuing the request.
  3. Inspect the error message - it echoes the exact invalid value received; fix that param.
  4. Check for empty/null params being stringified into the query string and omit them instead.

Example fix

// before
GET /ai/agentlogs?startDate=last-week
// after
GET /ai/agentlogs?startDate=2026-08-21
Defensive patterns

Strategy: validation

Validate before calling

const parsed = parseDate(rawDate)
if (!parsed || Number.isNaN(new Date(parsed).getTime())) {
  throw new Error(`startDate/endDate must be an ISO date, got: ${rawDate}`)
}

Type guard

const isParsableDate = (v: unknown): v is string => typeof v === "string" && parseDate(v) !== null

Try / catch

try {
  logs = await listLiteLLMLogs({ startDate, endDate })
} catch (e) {
  if (e.message.startsWith("Invalid LiteLLM date")) {
    return respond400("startDate/endDate must be ISO 8601 dates")
  }
  throw e
}

Prevention

When it happens

Trigger: Calling the LiteLLM log listing endpoints (via getLiteLLMDayBoundary through params) with a startDate/endDate query value that parseDate cannot parse - empty strings, arbitrary text, or unsupported formats.

Common situations: Builder UI or API clients sending malformed date query params (e.g. 'yesterday', '2026-13-45', or an empty value); timezone-format mismatches between client and server expectations.

Related errors


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