Fixes#23305.
Removing a junction relation soft-deletes the intermediate junction
record. Re-adding the same relation created a brand new record, which
the composite unique index on the junction object (e.g. `personId` +
`companyId`) rejected with "This record already exists".
`useUpdateJunctionRelationFromCell` now creates the junction record
through `useCreateManyRecords` with `upsert: true`. The server matches
on the unique index with `withDeleted()` and clears `deletedAt` on the
matched row instead of inserting.
## This revives, it does not create
Worth being explicit, because it is a deliberate trade and not obvious
from the diff.
When a soft-deleted row exists for the pair, the user gets that row
back. Same id, same `createdAt`, same `createdBy`, and anything attached
to it (notes, files, and any fields the app added to the junction
object). Verified on a dev instance: after re-adding a link through the
picker, the row still reported a creation date from days earlier.
That is fine for a pure link. It is a lie for a junction that carries
data, for instance a `PersonCompanyRelationship` with a role and dates.
The alternative designs are hard-deleting on detach (needs
`canDestroyObjectRecords` on the junction object, which most roles do
not grant) and partial unique indexes (needs `indexWhereClause` exposed
to app-declared indexes, which the SDK does not support today). Both are
larger changes. This one unblocks affected apps without requiring
anything from them.
Note that upsert conflict detection ignores `indexWhereClause`, so
shipping partial indexes later would not change this behaviour on its
own.
## Why the id handling changed
The hook no longer sends a client-generated id. Under upsert the server
decides which row you get, so the id in the input would be discarded.
The optimistic store entry still uses a local id so the chip appears
immediately, then adopts the persisted id once the mutation resolves.
Without that, a revive left an id in the store that exists nowhere on
the server, and the next removal failed with "This record does not exist
or has been deleted".
Supersedes #23365, which took the same approach but added `$upsert` to
the shared `createOne` mutation. That capability already exists per call
on `createMany`, and widening the shared document broke the
`useCreateOneRecordMutation` and `useCreateOneRecord` tests.
## Testing
Verified end to end on a dev instance with a junction object carrying a
non-partial composite unique index, since the dev seed does not create
one and the bug cannot reproduce without it:
- before: re-adding after a removal fails with "This record already
exists"
- after: the original row is restored, `deletedAt` cleared, one row
throughout, and removing again in the same session works, with no
GraphQL errors
Added an integration test for the path this depends on: a soft-deleted
record matched on its unique fields alone, with no id in the input. The
existing coverage only exercised upsert by explicit id.
## Known gaps, deliberately not addressed here
**Toggling a link off while its creation is still in flight.** The store
id is provisional until the mutation returns, so a removal issued inside
that window deletes an id the server never received. Reproduced by
stalling the create and clicking remove during it:
`CombinedGraphQLErrors: Record not found`, and the link stays active
despite the user removing it. The window is one mutation round trip.
Left for a follow-up; the likely fix is a per-record operation queue so
adds and removes on a field run in click order.
**Junction objects with no unique index.** Remove then re-add still
creates a duplicate row there, on this branch as on main, because
conflict detection is driven by unique indexes.
---------
Co-authored-by: Shinu Cherian <129690295+Shinu-Cherian@users.noreply.github.com>
## Context
The `createMany` upsert path resolved conflicts by scanning individual
field
metadata and only treating a field as a conflict target when it was
flagged
`isUnique` (plus the primary `id`). This ignored **composite unique
indexes**
(multi-column unique constraints), so upserting against a multi-field
unique
key never matched an existing row and could either insert a duplicate or
fail.
## What changed
- **Conflict groups are now derived from unique indexes**, not from
per-field
`isUnique` flags. `getConflictingFields` reads the object's index
metadata
(`flatIndexMaps`) and builds one `ConflictingFieldGroup` per unique
index
(the primary `id` remains its own group).
- Each index group correctly expands its fields into DB columns,
handling:
- **Composite field types** — expands to the sub-columns included in the
unique constraint (or a specific sub-field when the index targets one).
- **`MANY_TO_ONE` relation fields** — resolves to the join column name.
- **Scalar fields** — used directly.
- `ConflictingFieldGroup.baseField: string` → **`baseFields:
string[]`**, since
a composite index spans multiple fields.
- **Clearer multi-match error message**: conflicting values are now
grouped per
index (`baseFields (fullPath: value, ...)`, groups joined by `;`) so
it's
obvious which unique key caused the ambiguity when a payload matches
different rows across different indexes.
- `CommonCreateManyQueryRunnerService` now fetches `flatIndexMaps` via
`WorkspaceManyOrAllFlatEntityMapsCacheService` and passes them into
`getConflictingFields`; the cache module is wired into
`CoreCommonApiModule`.
## Tests
- New integration suite
`composite-unique-index-upsert.integration-spec.ts`:
- single composite unique index — insert, update-on-match, and
insert-when-key-differs
- **two independent composite unique indexes** — happy path (single row
matches
both) and failure path (payload matches different rows across the two
indexes → `Multiple records found with the same unique field values` /
`BAD_USER_INPUT`).
- Updated unit specs for `get-conflicting-fields`,
`get-matching-record-id`,
`build-where-conditions`, and `categorize-records` to reflect the
index-driven grouping and the `baseFields[]` shape.
## Test plan
- [ ] `npx nx run twenty-server:test:integration:with-db-reset --
composite-unique-index-upsert`
- [ ] `npx nx test twenty-server -- get-conflicting-fields
get-matching-record-id build-where-conditions categorize-records`
- [ ] Manual: upsert against a composite unique index updates the
matching row instead of inserting a duplicate.
fixes
https://github.com/twentyhq/twenty/issues/22580#issuecomment-4894266699
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/22604?utm_source=github"
target="_blank" rel="noopener noreferrer"
data-no-image-dialog="true"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source
media="(prefers-color-scheme: light)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img
alt="Review in cubic"
src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a>
<!-- End of auto-generated description by cubic. -->
## Fix: upsert no longer rewrites `position` on existing records
### Problem
`createX(..., upsert: true)` resets the `position` of records that
resolve to an **update**, even when the payload doesn't include a
`position`.
The create-many/upsert runner backfills `position` (to `"first"`) in
`computeArgs` over the **whole batch**, before records are split into
insert vs update. So existing rows get a freshly recomputed `position`
written on every upsert. For callers that re-upsert their full dataset
on a schedule (e.g. a daily sync), this rewrites `position` for every
record on each run and drifts the values steadily negative — and it
floods audit/event logs with position churn.
The dedicated `updateOne`/`updateMany` runners already pass
`shouldBackfillPositionIfUndefined: false`; the upsert path did not.
### Fix
Only backfill `position` for records that are actually inserted:
- `computeArgs` now passes `shouldBackfillPositionIfUndefined:
!args.upsert` in both the create-many and create-one runners, so
undefined positions are left untouched on upsert.
- `performUpsertOperation` backfills `"first"` positions for
`recordsToInsert` only, **after** categorization, via
`RecordPositionService`.
Explicit `position` values (`"first"`, `"last"`, or a number) in the
payload are still honored. Plain (non-upsert) create behavior is
unchanged.
### Behavior
| Scenario | Before | After |
|---|---|---|
| Upsert updates existing row, no `position` sent | `position` rewritten
| `position` untouched |
| Upsert inserts new row, no `position` sent | gets `"first"` | gets
`"first"` (unchanged) |
| Explicit `position` on upsert | applied | applied |
| Plain create | unchanged | unchanged |
groupBy fix: when a group's dimension value is NULL, we need to adapt
the raw sql (stage: NULL -> stage IS NULL)
typeMapper fix: a graphql type should be made non-nullable if was
indicated so + does not have a default value. our check on not having a
default value was limited to having a null defaultValue instead of
having a null or undefined defaultValue. This is a breaking change, but
all the queries that were providing a null value for these args were not
functioning anyway, and luckily in the FE we declared all queries adding
a `!` already.
## Introduction
After enabling flag by default got following errors:
```ts
Test Suites: 48 failed, 1 skipped, 97 passed, 145 of 146 total
Tests: 499 failed, 1 skipped, 644 passed, 1144 total
Snapshots: 61 failed, 133 passed, 194 total
Time: 363.226 s
Ran all test suites.
```
## From
<img width="2952" height="1510" alt="image"
src="https://github.com/user-attachments/assets/7e3b20c6-2552-40a7-90bb-2d7b3002c895"
/>
## To
<img width="3134" height="1510" alt="image"
src="https://github.com/user-attachments/assets/4fc9ada4-3c14-4333-a1db-11daf87db8d6"
/>
There's a huge test bundle in the latest shard that we could split up
## Notes
- Set as failing morph relation field rename as for the moment we do not
handle relation field mutation
- fixed the object update and creation validation adding label
identifier field metadata id checks
- and more
Some integrations tests are still on the v1 ( they have before and after
all disabling and re-enabling the flat ) but mainly we now have more
coverage on the v2 than the v1.
Mainly related records, uniqueness have to be migrated the v2 and so
tests too
Thomas Trompette
