## Fix: crash on Settings → Object → Search after changing label
identifier
### Problem
Opening the Search section (or changing an object's label identifier)
threw
`t.searchFieldMetadatas is not iterable` in
`SettingsObjectSearchSection`.
### Root cause
`EnrichedObjectMetadataItem.searchFieldMetadatas` is typed as a
non-optional
array, but at runtime it can be `undefined`. `useLoadMinimalMetadata`
stores the
minimal objects with `objectMetadataItems as unknown as
FlatObjectMetadataItem[]`.
The minimal query doesn't select `searchFieldMetadataList`, so the
double-cast
hides that the property is missing. Until the full metadata reload
lands, the
object has no `searchFieldMetadatas`, and
`objectMetadataItemsWithFieldsSelector`
spreads that `undefined` straight through to the component, which
spreads it
(`[...searchFieldMetadatas]`) and crashes.
(`fields`/`indexMetadatas` never hit this because they come from
`Map.get()`,
which is honestly typed as `| undefined` and already falls back to
`[]`.)
### Fix
Guarantee the array contract in `objectMetadataItemsWithFieldsSelector`,
matching
how `fields`/`indexMetadatas` are already defaulted:
`searchFieldMetadatas: flatObject.searchFieldMetadatas ?? []`.
### Tradeoff considered
The "clean" alternative is promoting `searchFieldMetadatas` to its own
metadata-store entity (like `indexMetadataItems`), which would make the
`?? []`
type-mandated via `Map.get`. Rejected for now: it's a medium
cross-package
refactor (new store key, type, selectors, split/reload wiring, plus a
server-side
collection hash for staleness) for an entity that is never independently
mutated —
it only changes as a side effect of label-identifier/field updates, so
independent
caching buys nothing. The selector default fixes the crash with minimal
surface
area; the deeper cleanup (making the `as unknown as` cast honest, or
splitting the
store) can be deferred until search-field metadata becomes directly
editable.
Paul Rastoin
36e89c04ad