Describe the bug
The docs state that createdAt, updatedAt, and id are built-in columns that "you can still filter and sort on". Sorting on these works. Filtering on them does not. Any filter referencing a built-in column silently matches nothing and returns an empty result set.
To Reproduce
Via the v1 API:
GET /api/v1/tables/{tableId}/rows?workspaceId={wsId}&filter={"createdAt":{"$gte":"2026-07-24T03:00:00.000Z","$lte":"2026-07-25T02:59:59.999Z"}}
With a string value, returns 400 Bad Request:
{
"error": "Range operator on column \"createdAt\" (number) requires a number, got string"
}
With a numeric value (Unix timestamp)
{ "rows": [], "rowCount": 0, "totalCount": 0 }
Passes validation, but returns empty results. No error, no warning, just zero rows regardless of how many rows match the range.
Expected behavior
Filters on createdAt / updatedAt / id compare against the top-level row columns (user_table_rows.createdAt, etc.) and return matching rows, mirroring the behavior the sort builder already provides.
Additional context
I think I can open a PR to solve this, if this intend to work the way I've described it.
Describe the bug
The docs state that createdAt, updatedAt, and id are built-in columns that "you can still filter and sort on". Sorting on these works. Filtering on them does not. Any filter referencing a built-in column silently matches nothing and returns an empty result set.
To Reproduce
Via the v1 API:
With a string value, returns 400 Bad Request:
With a numeric value (Unix timestamp)
Passes validation, but returns empty results. No error, no warning, just zero rows regardless of how many rows match the range.
Expected behavior
Filters on createdAt / updatedAt / id compare against the top-level row columns (user_table_rows.createdAt, etc.) and return matching rows, mirroring the behavior the sort builder already provides.
Additional context
I think I can open a PR to solve this, if this intend to work the way I've described it.