Budibase/budibase · error

Unsupported operator: ${operator}

Error message

Unsupported operator: ${operator}

What it means

A plain Error thrown by buildCondition in packages/shared-core/src/filters.ts when the operator passed for a filter is not one the builder supports. The function only reaches this branch when the operator falls outside the recognised operator set used to build query predicates, meaning the caller supplied an unknown/misspelled operator string or an operator valid in a different filter context (e.g. legacy vs structured filters).

Source

Thrown at packages/shared-core/src/filters.ts:504

      // Transform boolean filters to cope with null.  "equals false" needs to
      // be "not equals true" "not equals false" needs to be "equals true"
      if (operator === "equal" && value === false) {
        query.notEqual = query.notEqual || {}
        query.notEqual[field] = true
      } else if (operator === "notEqual" && value === false) {
        query.equal = query.equal || {}
        query.equal[field] = true
      } else {
        query[operator] ??= {}
        query[operator][field] = value
      }
    } else {
      query[operator] ??= {}
      query[operator][field] = value
    }
  } else {
    throw new Error(`Unsupported operator: ${operator}`)
  }

  return query
}

export interface LegacyFilterSplit {
  allOr?: boolean
  onEmptyFilter?: EmptyFilterOption
  filters: SearchFilter[]
}

export function splitFiltersArray(filters: LegacyFilter[]) {
  const split: LegacyFilterSplit = {
    filters: [],
  }

  for (const filter of filters) {
    if ("operator" in filter && filter.operator === "allOr") {

View on GitHub (pinned to a81a902e9a)

Solutions

1. Check the operator value at the failing call site against the supported operator enum in shared-core filters (use the Operators/enum exports rather than raw strings).
2. Fix typos and case: operators are matched exactly.
3. If migrating from legacy filters, convert the legacy operator names to the current equivalents.
4. Add a whitelist/lookup of allowed operators in the caller before building the condition.

Example fix

// before
buildCondition({ operator: "equalss", field: "name", value: "x" })
// after
import { Operators } from "@budibase/shared-core"
buildCondition({ operator: Operators.EQUAL, field: "name", value: "x" })

import { Operators } from "@budibase/shared-core"
const ALLOWED = new Set<string>(Object.values(Operators))
if (!ALLOWED.has(filter.operator)) {
  throw new Error(`Operator '${filter.operator}' not supported; allowed: ${[...ALLOWED].join(", ")}`)
}

function isSupportedOperator(op: string): op is Operators {
  return (Object.values(Operators) as string[]).includes(op)
}

try {
  const query = buildSearchQuery(filters)
} catch (e) {
  if (e.message.startsWith("Unsupported operator")) {
    console.warn(`Bad operator in filters: ${e.message}; falling back to EQ`)
    return buildSearchQuery(filters.map(f => ({ ...f, operator: Operators.EQUAL })))
  }
  throw e
}

When it happens

Trigger: Calling a search/query API (or building a filter programmatically) with an operator string like "like", "not_equal" variants, or a typo such as "equalss" that the filter builder does not recognise.

Common situations: Migrating from legacy filter syntax to the newer structured filters where operator names changed; hand-written JSON filters in API clients; building operators dynamically from user input or a mapping table that is out of date with shared-core.

Related errors

• Invalid import url
• Only HTTP(S) URLs are allowed for query import
• Import url must not contain credentials
• attempted to create a table without specifying the table to
• Error getting status

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