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

Project	Deployment	Actions	Updated (UTC)
docs	Ready	Preview, Comment	Jun 9, 2026 10:05pm

@greptile review

PR Summary

Low Risk
Small UI-only alignment with existing id-keyed query/filter data; no auth, API, or persistence changes beyond correct field keys in filter state.

Overview
Fixes table filtering and delete confirmation after stable column ids: filter rules now store getColumnId keys (with column names as labels), and the single-column delete modal shows the resolved display name instead of a raw col_… id.

TableFilter now takes ColumnDefinition[], builds dropdown values from stable ids, and shows the selected column label via lookup. New rules default to the first column’s id, not its name.

table.tsx maps deletingColumns[0] through columns + getColumnId for the confirm copy only; delete behavior is unchanged.

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

Greptile Summary

This PR fixes two related regressions following the stable-column-ids change in #4898: filter rules now use getColumnId for column option values (so filters match on the stable id rather than the mutable display name), and the delete-column confirmation modal resolves the stored column id back to a human-readable name.

• table-filter.tsx: TableFilterProps.columns is tightened to ColumnDefinition[]; columnOptions maps each column to { value: getColumnId(col), label: col.name }; the selected-column display label resolves via the options lookup, with graceful fallback; createRule seeds the default column field with the stable id.
• table.tsx: The single-column delete confirmation now resolves deletingColumns[0] (a col_… id) back to the column's display name via columns.find(…)?.name, with a raw-id fallback for any column not found in the current schema.

Confidence Score: 5/5

Safe to merge; the changes are narrow, targeted, and correctly restore filter matching and the delete-column modal UX after the stable-id migration.

Both changed code paths have the correct logic: filter rules now carry stable column ids so queries match row data, and the delete modal performs a proper id→name lookup with a sensible fallback. Backward compatibility with legacy name-keyed columns is preserved because getColumnId falls back to the column name when no id is present.

No files require special attention.

Important Files Changed

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[TableFilter receives ColumnDefinition array] --> B[columnOptions: value=getColumnId, label=col.name]
    B --> C[FilterRuleRow dropdown keyed by stable id]
    C --> D{User selects column}
    D --> E[rule.column = stable col id]
    E --> F[Display: find col where value matches rule.column]
    F --> G[filterRulesToFilter builds Filter keyed by col id]
    G --> H[API query matches row data keys correctly]

    I[Delete column triggered] --> J[deletingColumns holds stable col id]
    J --> K[Confirm modal: find column where getColumnId matches]
    K --> L[Shows human-readable column name]

_{Reviews (4): Last reviewed commit: "fix(tables): import getColumnId from col..." | Re-trigger Greptile}

Greptile Summary

This PR fixes two regressions introduced by the stable-column-ids change (#4898): filter rules were still keying on column display names instead of stable ids (so no rows ever matched), and the delete-column confirm modal was surfacing raw col_… ids to users.

• TableFilter now uses getColumnId when building columnOptions values and when initializing a new FilterRule, ensuring rule.column always carries the stable id that the query layer expects; the dropdown display resolves the id back to a label via a map lookup with a safe fallback.
• The delete-column confirm modal resolves deletingColumns[0] (a stable column id) back to the column's display name through columns.find(...getColumnId...)?.name, with a fallback to the raw id for robustness.

Confidence Score: 4/5

Safe to merge. Both changed files make targeted, self-contained fixes that restore expected behaviour without touching any shared utilities or data layer.

The filter key fix and the delete-modal name resolution are both correct. The one remaining rough edge — const names = deletingColumns aliasing stable column ids under a misleading variable name — is a pre-existing naming holdover and does not affect runtime behaviour.

No files require special attention beyond the minor naming note in table.tsx.

Important Files Changed

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["ColumnDefinition[]\n(id?, name, type)"] --> B["getColumnId(col)\n→ col.id ?? col.name"]
    B --> C["columnOptions\n{ value: colId, label: colName }"]
    C --> D["FilterRuleRow dropdown\nonSelect → rule.column = colId"]
    D --> E["FilterRule\n{ column: colId, operator, value }"]
    E --> F["filterRulesToFilter(rules)\n→ Filter { colId: condition }"]
    F --> G["Query layer\nmatches row.data[colId] ✓"]

    H["Existing filter prop\n(Filter keyed by colId)"] --> I["filterToRules(filter)\n→ FilterRule[] { column: colId }"]
    I --> D

    J["Display in dropdown trigger"] --> K{"columns.find(col =>\ncol.value === rule.column)"}
    K -->|found| L["show col.label (display name)"]
    K -->|not found| M["show rule.column as fallback"]

_{Reviews (1): Last reviewed commit: "fix(tables): key filter UI by stable col..." | Re-trigger Greptile}

@greptile review