Follow-up to #4328, which added searchable-field-unknown — a gating lint for a searchableFields entry that names no field on the object.
That rule covers the metadata surfaces: an object's own ADR-0061 declaration (objects[].searchableFields), its built-in named list views (objects[].listViews.<k>.searchableFields), and a defineView aggregate's default list / named listViews.
It does not cover the React page surface. ListView declares searchableFields as a dataProp:
https://github.com/objectstack-ai/objectstack/blob/main/packages/spec/src/ui/react-blocks.ts#L91
dataProps: ['columns', 'sort', 'searchableFields', 'userFilters', 'pagination', …]
so a React page can write <ListView objectName="showcase_account" searchableFields={['no_such']} /> and nothing resolves that name. validate-react-page-props.ts only checks chart axes / aggregate coherence today; validate-page-field-bindings.ts covers the page-component properties bag, and its descriptor table names searchFields for element:record_picker but nothing for the React ListView block.
The failure is the same one #4328 documents: the engine's resolveSearchFields silently filters a stale name out, so the search either scans a narrower set than the page asked for or — once every entry is stale — falls through to the auto-default and scans a wider one. Once the REST read path validates the $searchFields override (#4254), a stale prop becomes a 400 INVALID_FIELD on that list.
Suggested fix: extend the descriptor table in validate-page-field-bindings.ts (or validate-react-page-props.ts, whichever owns React block dataProps) to resolve searchableFields against the block's bound object, reusing the same skips validate-searchable-fields.ts established — unknown object, no authored field map, registry-injected system columns — so the two surfaces agree on what counts as a field.
The one live instance today is clean (examples/app-showcase/src/ui/pages/renewals-pipeline.page.ts:97 → searchableFields={['name']}), so this is a gap to close before it bites, not a live bug.
Follow-up to #4328, which added
searchable-field-unknown— a gating lint for asearchableFieldsentry that names no field on the object.That rule covers the metadata surfaces: an object's own ADR-0061 declaration (
objects[].searchableFields), its built-in named list views (objects[].listViews.<k>.searchableFields), and adefineViewaggregate's defaultlist/ namedlistViews.It does not cover the React page surface.
ListViewdeclaressearchableFieldsas a dataProp:https://github.com/objectstack-ai/objectstack/blob/main/packages/spec/src/ui/react-blocks.ts#L91
so a React page can write
<ListView objectName="showcase_account" searchableFields={['no_such']} />and nothing resolves that name.validate-react-page-props.tsonly checks chart axes / aggregate coherence today;validate-page-field-bindings.tscovers the page-componentpropertiesbag, and its descriptor table namessearchFieldsforelement:record_pickerbut nothing for the ReactListViewblock.The failure is the same one #4328 documents: the engine's
resolveSearchFieldssilently filters a stale name out, so the search either scans a narrower set than the page asked for or — once every entry is stale — falls through to the auto-default and scans a wider one. Once the REST read path validates the$searchFieldsoverride (#4254), a stale prop becomes a400 INVALID_FIELDon that list.Suggested fix: extend the descriptor table in
validate-page-field-bindings.ts(orvalidate-react-page-props.ts, whichever owns React block dataProps) to resolvesearchableFieldsagainst the block's bound object, reusing the same skipsvalidate-searchable-fields.tsestablished — unknown object, no authored field map, registry-injected system columns — so the two surfaces agree on what counts as a field.The one live instance today is clean (
examples/app-showcase/src/ui/pages/renewals-pipeline.page.ts:97→searchableFields={['name']}), so this is a gap to close before it bites, not a live bug.