## Summary
Fixes a pre-existing regression where rebuilding a `TS_VECTOR`
(`searchVector`) generated column drops its GIN index without recreating
it, leaving search correct but **unindexed** (sequential scan).
Changing a generated column's expression requires `DROP COLUMN` + `ADD
COLUMN` (Postgres can't `ALTER` a generated expression). The
`searchVector`'s GIN index is a separate index-metadata entity built on
that column, so the `DROP COLUMN` cascade-drops the physical index — and
the rebuild branch never re-issued `CREATE INDEX`. This existed on
`main` (triggered by `asExpression`/`generatedType` settings changes)
and was inherited by the `rebuildSearchVector` refactor in #22287.
This is the first, self-contained part of
https://github.com/twentyhq/core-team-issues/issues/2620. The 2.18
recompute/backfill workspace command is intentionally left for a
follow-up PR.
## What changed
### Runner loads the maps a rebuild needs
`workspace-migration-runner.service.ts` — `fieldMetadata` declares
neither `searchFieldMetadata` nor `index` as a related metadata name, so
a `fieldMetadata`-only rebuild action had neither
`flatSearchFieldMetadataMaps` (needed by the expression derivation) nor
`flatIndexMaps` (needed to recreate the index) in context. The runner
now detects `update` actions carrying `rebuildSearchVector === true` and
loads those two maps — **only** when a rebuild is present, so ordinary
field operations are unaffected.
### Handler recreates the index after re-adding the column
`update-field-action-handler.service.ts` — in the rebuild branch, after
`addColumns`, recreate the field's single GIN index:
```ts
const [searchVectorFlatIndexMetadata] = findFieldRelatedIndexes({
flatFieldMetadata: optimisticFlatFieldMetadata,
flatObjectMetadata,
flatIndexMaps,
});
if (isDefined(searchVectorFlatIndexMetadata)) {
await createIndexInWorkspaceSchema({ flatIndexMetadata: searchVectorFlatIndexMetadata, ... });
}
```
- **Narrow lookup, not a workspace-wide scan.** The flat field has no
index back-reference (`fieldMetadata.indexFieldMetadatas` is `null` in
`ALL_ONE_TO_MANY_METADATA_RELATIONS`). The *object* does aggregate its
indexes (`indexMetadataIds`), so we reuse the existing
`findFieldRelatedIndexes` helper — already used by
`handle-index-changes-during-field-update.util.ts` and the morph-rename
path — which resolves only this object's indexes and filters to the one
on the field.
- A `TS_VECTOR` field has exactly one index (the standard
`searchVectorGinIndex`), so we retrieve that single index rather than
iterating. `createIndex` emits `CREATE INDEX IF NOT EXISTS`
(idempotent).
This makes the rebuild self-contained (column + index move together) and
fixes every rebuild path: rename, label-identifier change, and
`searchFieldMetadata` changes.
### Regression test
Extends
`update-one-field-metadata-search-vector-side-effect.integration-spec.ts`
to query `pg_indexes` before and after the rename and assert the GIN
index on the `searchVector` column persists (not just that search still
returns the record). Fails without the fix, passes with it.
## Test plan
- [x] `npx nx lint:diff-with-main twenty-server` — 0 warnings, 0 errors
- [x] `npx nx typecheck twenty-server` — clean for changed files
- [ ] Integration: extended rename-rebuild spec (GIN index present
post-rebuild)
Part of https://github.com/twentyhq/core-team-issues/issues/2620
Paul Rastoin
fe644a0630