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
- Send dates in an ISO 8601 format the parser supports, e.g. 2026-08-28 or 2026-08-28T10:00:00Z.
- Validate/parse dates on the client before issuing the request.
- Inspect the error message - it echoes the exact invalid value received; fix that param.
- 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
- Always send ISO 8601 dates (2026-08-28 or with time/Z)
- Validate query params before calling the API
- Omit date params rather than sending empty strings
- Fix the echoed value in the error message - it names the exact bad input
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
- Invalid ${queryName} query
- Invalid ${label}: ${value}
- Expected at least one valid date, received '${a}' and '${b}'
- Error getting status
- OIDC Config contents invalid
AI-assisted analysis of Budibase/budibase@a81a902e9a (2026-08-29).
Data as JSON: /api/errors/bf31142364202f09.
Report an issue: GitHub.