## Issue
Reported in quality-feedbacks: **"Issues with morph relation view
field"** — a morph relation column added to a view **disappears after
refresh** (and can be added several times).
## Root cause — the SSE metadata sync
A morph relation is stored as **one `fieldMetadata` row per target
object**, all sharing a `morphId`. Collapsing those rows into the single
field that represents the relation is a **read-time projection** in the
server's `objects.fieldsList` resolver — it is *not* a storage
invariant, and the rows are never merged.
The frontend metadata store is kept in sync with the raw rows **one row
at a time over SSE** (`MetadataStoreSSEEffect`): every metadata change
broadcasts a single created/updated record that's pushed straight into
the store. Creating a morph relation creates N rows (one per target), so
**N `create` events arrive and N raw sub-fields land in the store —
bypassing the `fieldsList` projection entirely.**
The view-field pickers read straight from that store, so they saw the
morph relation **once per target**. Each could be added as a column
referencing a different sub-field id; after a refresh the view reloads
from the projected (deduped) data, the non-survivor columns no longer
resolve, and they disappear.
## Fix & architecture note
Because the store deliberately mirrors raw rows (that's what the SSE
sync maintains), the fix applies the **same read-time projection on the
client** — deduping morph rows by `morphId` in
`useActiveFieldMetadataItems` — rather than filtering rows at each
insert path (SSE, optimistic create, …). This matches how the backend
already models morph fields and is robust regardless of which path
delivered the rows.
The survivor-selection rule (which sub-field id represents the relation)
now lives in `twenty-shared` (`pickMorphGroupSurvivor`) so client and
server can't drift.
Charles Bochet
0a99f784eb