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

  1. Inspect the agent-log record feeding addSessionLog and confirm its timestamp fields are valid ISO strings
  2. Check for a LiteLLM version change that renamed or reformatted timestamp fields and update the mapping
  3. Sanitize/normalize timestamps when writing rows so unparseable values never reach minDate
  4. 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

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


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