Custom object relations: writes succeed but reads return null

[daniel-ospina]

Bug Description

Created a custom object "Investor Lead" with a relation field "fund" (→ Companies). The GraphQL create/update mutations DO NOT expose the relation field for writes. The investorPipelineId field exists on the Company update mutation (reverse relation) and calls succeed, but reading back the fund field on the Investor Lead returns null.

To Reproduce

1. Create custom object "Investor Lead" with a relation field to Companies
2. Try to create or update an Investor Lead with fundId - field doesn't exist on mutation input
3. Try updateCompany(investorPipelineId: lead.id) - succeeds
4. Query investorLead.fund - returns null

Expected

Relation fields on custom objects should be writable via create/update mutations, just like personId/person work on the same object.

Environment

• Twenty version: 2.25.x (Docker, latest)
• API: GraphQL + MCP

Impact

Cannot programmatically link custom object records to related objects. Makes API-driven workflows impossible for custom objects.

[sonarly]

🟠 Sonarly Analysis — High Severity

One-to-many custom relation is not writable as fundId

The reported custom relation was created with the custom object on the one-to-many side. Twenty intentionally omits source-side FK and connect inputs for one-to-many fields, so the expected fundId mutation field is absent. The reported null read cannot be fully verified without the exact query response and workspace metadata snapshot.

Root Cause

The proximate cause is the relation direction stored in metadata: the custom object's fund field is on the ONE_TO_MANY side, while the inverse Company field is MANY_TO_ONE. This is established by the reported schema asymmetry: fundId is absent from the custom object's mutation input, while the inverse investorPipelineId field exists on the Company mutation. Relation-pair generation explicitly assigns the inverse relation type when it creates the target field [ref:relation-pair-generator-read].

The GraphQL schema generator intentionally returns no mutation fields for a one-to-many relation:

if (fieldMetadata.settings?.relationType === RelationType.ONE_TO_MANY)
  return {};

This applies both to the scalar FK input and to the nested connect input [ref:relation-input-generator-read]. The runtime data processor enforces the same rule and raises One-to-many relation ... field does not support write operations if such a field reaches the write path [ref:data-arg-processor-read]. Therefore, the missing fundId field is not caused by custom-object detection failing; it is the designed result of the relation being created in the one-to-many direction.

The inverse investorPipelineId field exists because only a MANY_TO_ONE relation receives a join column. The ORM relation factory and schema relation resolver both derive a join column only for the many-to-one side [ref:entity-schema-relation-factory-read] [ref:determine-schema-relation-details-read]. The one-to-many fund field is exposed as a relation connection with findMany arguments, not as a scalar record with an Id input [ref:object-metadata-relations-generator-read].

The triggering cause was the custom relation's metadata configuration, not traffic, resource exhaustion, or a deployment load pattern: the relation was provisioned with ONE_TO_MANY on the custom object's field. The exact initiating payload or UI/MCP action is unavailable, so whether the direction was selected by a user or generated by a client cannot be established.

The reported null read is not independently proven to be a server read defect. The one-to-many read path looks up the inverse many-to-one join column on the target records and assigns matching records to the source relation connection [ref:process-nested-relations-read]. To determine why the reported connection was empty, the exact selection shape and the workspace's two relation metadata records plus the target database row are required.

Blame commit: 06605b2f by etiennejouan — simplify gql schema gen (#14426)

Suggested Fix

Updated the GraphQL relation field descriptions so ONE_TO_MANY fields explicitly state that they are read-only on the current object and identify the inverse MANY_TO_ONE field, including its <fieldName>Id mutation input.

Structured the MCP relation creation payload schema and documented the direction semantics consistently across single-field, batch-field, and batch-relation tools. MCP clients are now guided to use MANY_TO_ONE when the source record should own and write a relation ID, while ONE_TO_MANY relations are clearly described as collection fields written through their inverse.

---

Analyzed by Sonarly · View full analysis

[bhardwajparth51]

@etiennejouan @BOHEUS open for external contributions?