fix(tables): fix the filter on built in timestamp columns

[tusharmotwani1718]

Summary

Fixes filtering on the built-in timestamp columns (created_at and updated_at) in the Table block.

Previously, filters on these built-in columns incorrectly treated them as JSON fields, causing type validation errors or returning zero rows. This change queries the built-in PostgreSQL timestamp columns directly instead of the JSON data column.

Fixes #5920

Type of Change

• Bug fix

Testing

Verified the fix by applying comparison filters ($gt, $gte, $lt, $lte, $eq) on the built-in created_at and updated_at columns and confirming that the expected rows are returned.

Also added/updated unit tests covering built-in timestamp column filtering.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

Screenshots/Videos

Before the fix, applying filters on the built-in timestamp columns (created_at, updated_at) resulted in validation errors:

Additionally, even when providing a Unix timestamp, the query returned zero rows because the filters were applied against the JSON data column instead of the built-in timestamp columns.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Jul 27, 2026 3:39pm

[cursor]

PR Summary

Medium Risk
Changes core table query SQL generation for a common filter path; scope is narrow but incorrect column naming could break queries at runtime.

Overview
Fixes Table block filters on built-in timestamp fields (created_at, updated_at, createdAt, updatedAt) that previously went through the JSON data column and failed validation or returned no rows.

The SQL filter builder now treats those names as real table columns: equality uses column = value::timestamptz instead of data @>, and range operators compare table.column with ::timestamptz instead of data->>'field'. A shared isBuiltInDateField helper in table API utils drives that branching; unit tests cover created_at for $gt and $eq.

^{Reviewed by Cursor Bugbot for commit 56cb60b. Bugbot is set up for automated code reviews on this repo. Configure here.}

[greptile-apps]

Greptile Summary

This PR redirects equality and range filters for built-in timestamp fields from JSON row data to PostgreSQL timestamp columns.

• Adds a helper that identifies built-in date fields.
• Uses direct timestamp-column comparisons for containment and range clauses.
• Imports the new predicate from the table API utility into the shared SQL builder.
• Includes incidental formatting changes in the table API utilities.

Confidence Score: 3/5

This PR should not merge until built-in timestamp detection accepts the field names used by table filters.

The UI and existing sort path use createdAt and updatedAt, but the new predicate only recognizes created_at and updated_at, so reachable filters continue down the incorrect JSONB path; the shared SQL builder also imports the predicate from an API-layer module.

Files Needing Attention: apps/sim/app/api/table/utils.ts, apps/sim/lib/table/sql.ts

Important Files Changed

Filename	Overview
apps/sim/app/api/table/utils.ts	Adds built-in timestamp detection, but recognizes snake_case names while callers expose camelCase names.
apps/sim/lib/table/sql.ts	Routes recognized timestamp filters to physical columns, but the naming mismatch leaves the normal filter path unfixed and the helper import crosses from the shared library into the API layer.

_{Reviews (1): Last reviewed commit: "fix[table-block]: fix filtering on built..." | Re-trigger Greptile}

[cursor]

Circular lib-app import

Medium Severity

isBuiltInDateField lives in app/api/table/utils.ts, which already imports buildFilterClause from @/lib/table, while lib/table/sql.ts now imports that helper back from the API utils module. That inverts the layering and creates a circular dependency between the SQL builder and the route utils.

Additional Locations (1)

• apps/sim/app/api/table/utils.ts#L290-L296

 

^{Reviewed by Cursor Bugbot for commit bc62aa7. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

There are 2 total unresolved issues (including 1 from previous review).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 56cb60b. Configure here.}

[cursor]

CamelCase fields hit wrong SQL columns

High Severity

isBuiltInDateField treats createdAt/updatedAt as built-in columns, then buildContainmentClause and buildComparisonClause interpolate that name via sql.raw into SQL. Postgres columns are created_at/updated_at, so camelCase filters resolve to a non-existent column and the query fails. The UI and sort path already use camelCase.

Additional Locations (1)

• apps/sim/app/api/table/utils.ts#L290-L296

 

^{Reviewed by Cursor Bugbot for commit 56cb60b. Configure here.}

[tusharmotwani1718]

the columns created_at/updated_at exist by default in a table. while fetching rows by query_rows, they exist in row.created_at/row.updated_at not inside row.data.columnName as for normal columns.