Budibase/budibase · error
Expected at least one valid date, received '${a}' and '${b}'
Error message
Expected at least one valid date, received '${a}' and '${b}' What it means
minDate returns the earliest of two optional date strings and throws when neither can be parsed, guaranteeing a non-optional ISO return value. It is called while building session rows (addSessionLog, startTime), so this surfaces when the underlying record's start timestamp is unparseable.
Source
Thrown at packages/server/src/sdk/workspace/ai/agentLogs/shared.ts:153
return undefined
}
return parsedDate
}
export function parseDateOrThrow(value: string, label: string): string {
const parsedDate = parseDate(value)
if (!parsedDate) {
throw new Error(`Invalid ${label}: ${value}`)
}
return parsedDate.toISOString()
}
export function minDate(a?: string, b?: string): string {
const firstDate = parseDate(a)
const secondDate = parseDate(b)
if (!firstDate && !secondDate) {
throw new Error(
`Expected at least one valid date, received '${a}' and '${b}'`
)
}
if (!firstDate) return secondDate!.toISOString()
if (!secondDate) return firstDate.toISOString()
return firstDate <= secondDate
? firstDate.toISOString()
: secondDate.toISOString()
}
export function maxDate(a?: string, b?: string): string {
const firstDate = parseDate(a)
const secondDate = parseDate(b)
if (!firstDate && !secondDate) {
throw new Error(
`Expected at least one valid date, received '${a}' and '${b}'`
)View on GitHub (pinned to a81a902e9a)
Solutions
- Inspect the agent-log record feeding addSessionLog and confirm its timestamp fields are valid ISO strings
- Check for a LiteLLM version change that renamed or reformatted timestamp fields and update the mapping
- Sanitize/normalize timestamps when writing rows so unparseable values never reach minDate
- Wrap the caller in error handling that skips rows with invalid timestamps instead of failing the whole session build
Example fix
// before const start = minDate(record.startTime, session.startTime) // after const parsedStart = parseDate(record.startTime) ?? parseDate(session.startTime) if (!parsedStart) return // skip malformed row const start = parsedStart.toISOString()
Defensive patterns
Strategy: type-guard
Validate before calling
if (!isValidDateParam(record.startTime) && !isValidDateParam(session.startTime)) {
return // skip malformed row before calling addSessionLog
} Type guard
function hasValidTimestamp(v: unknown): v is string {
return typeof v === "string" && !Number.isNaN(Date.parse(v))
} Try / catch
try {
addSessionLog(session, record)
} catch (err) {
if ((err as Error).message.includes("valid date")) {
console.error("Skipping session row with invalid timestamps", record)
return
}
throw err
} Prevention
- Normalize timestamps to ISO at ingestion
- Map LiteLLM timestamp fields after every version bump
- Skip/log malformed rows instead of failing the batch
- Validate records before building sessions
When it happens
Trigger: addSessionLog invoked with a LiteLLM session/request record whose startTime field is missing, null, or in an unparseable format — both a and b fail parseDate simultaneously.
Common situations: LiteLLM records missing the expected timestamp field after a schema/version change; corrupted or hand-edited log rows; timestamps stored in an unexpected format (epoch millis instead of ISO).
Related errors
- Invalid ${label}: ${value}
- Invalid ${queryName} query
- Invalid LiteLLM date: ${value}
- Invalid bookmark query
- Error getting status
AI-assisted analysis of Budibase/budibase@a81a902e9a (2026-08-29).
Data as JSON: /api/errors/dff452989abf6f86.
Report an issue: GitHub.