Migrate attachments to morph relations + fix morph join column filtering #17381
Conversation
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
1 issue found across 31 files
Prompt for AI agents (all issues)
Check if these issues are valid — if so, understand the root cause of each and fix them.
<file name="packages/twenty-server/src/database/commands/upgrade-version-command/1-17/1-17-migrate-attachment-to-morph-relations.command.ts">
<violation number="1" location="packages/twenty-server/src/database/commands/upgrade-version-command/1-17/1-17-migrate-attachment-to-morph-relations.command.ts:223">
P1: Feature flag enabling and cache operations after transaction commit can leave workspace in inconsistent state if they fail. Since the transaction is already committed, a failure here means database changes are persisted but the feature flag isn't set, causing the next migration attempt to fail on already-renamed columns. Consider enabling the feature flag before committing, or making the column renames idempotent by checking column existence first.</violation>
</file>
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
|
|
||
| this.logger.log(`✅ Successfully migrated attachment fieldmetadata`); | ||
|
|
||
| await queryRunner.commitTransaction(); |
There was a problem hiding this comment.
P1: Feature flag enabling and cache operations after transaction commit can leave workspace in inconsistent state if they fail. Since the transaction is already committed, a failure here means database changes are persisted but the feature flag isn't set, causing the next migration attempt to fail on already-renamed columns. Consider enabling the feature flag before committing, or making the column renames idempotent by checking column existence first.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At packages/twenty-server/src/database/commands/upgrade-version-command/1-17/1-17-migrate-attachment-to-morph-relations.command.ts, line 223:
<comment>Feature flag enabling and cache operations after transaction commit can leave workspace in inconsistent state if they fail. Since the transaction is already committed, a failure here means database changes are persisted but the feature flag isn't set, causing the next migration attempt to fail on already-renamed columns. Consider enabling the feature flag before committing, or making the column renames idempotent by checking column existence first.</comment>
<file context>
@@ -0,0 +1,258 @@
+
+ this.logger.log(`✅ Successfully migrated attachment fieldmetadata`);
+
+ await queryRunner.commitTransaction();
+
+ await this.featureFlagService.enableFeatureFlags(
</file context>
Greptile OverviewGreptile SummaryThis PR migrates attachments from individual relation fields to morph relations, following the pattern established by TimelineActivity. The migration is protected by the Key changes:
Implementation quality: Confidence Score: 4/5
Important Files Changed
Sequence DiagramsequenceDiagram
participant User
participant Frontend
participant Backend
participant Database
participant FeatureFlag
Note over Backend,Database: Migration Phase (1-17 Command)
Backend->>FeatureFlag: Check IS_ATTACHMENT_MIGRATED
alt Not Migrated
Backend->>Database: Rename columns (taskId → targetTaskId, etc.)
Backend->>Database: Update fieldMetadata type to MORPH_RELATION
Backend->>Database: Set shared morphId on all target fields
Backend->>FeatureFlag: Enable IS_ATTACHMENT_MIGRATED flag
Backend->>Backend: Invalidate and recompute cache
end
Note over User,FeatureFlag: Runtime - Attachment Upload
User->>Frontend: Upload attachment to entity
Frontend->>FeatureFlag: Check IS_ATTACHMENT_MIGRATED
alt Flag Enabled
Frontend->>Frontend: Use target{Entity}Id format
else Flag Disabled
Frontend->>Frontend: Use {entity}Id format
end
Frontend->>Backend: Create attachment with computed field name
Backend->>Database: Insert attachment record
Database-->>Frontend: Return created attachment
Note over Frontend,Database: Runtime - Attachment Query
Frontend->>FeatureFlag: Check IS_ATTACHMENT_MIGRATED
Frontend->>Frontend: Compute filter field name
Frontend->>Backend: Query attachments with filter
Backend->>Database: Execute query with join column
Database-->>Frontend: Return matching attachments
Frontend->>Frontend: Apply optimistic filtering
Frontend->>Frontend: Match morph relation join columns
Frontend-->>User: Display attachments
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
|
🚀 Preview Environment Ready! Your preview environment is available at: http://bore.pub:39070 This environment will automatically shut down when the PR is closed or after 5 hours. |
📊 API Changes ReportGraphQL Schema ChangesGraphQL Schema Changes[error] Error: Unable to read JSON file: /home/runner/work/twenty/twenty/current-schema-introspection.json: Not valid JSON content GraphQL Metadata Schema ChangesGraphQL Metadata Schema Changes[error] Error: Unable to read JSON file: /home/runner/work/twenty/twenty/current-metadata-schema-introspection.json: Not valid JSON content REST API Analysis ErrorError OutputREST Metadata API Analysis ErrorError Output
|
Closes 1744.
This PR migrates attachments to morph relations behind a feature flag, following the TimelineActivity pattern. it introduces the
IS_ATTACHMENT_MIGRATEDflag, updates standard field metadata and indexes to use morph relations, adds a workspace migration that renamesattachment.*Idcolumns totarget*Idand converts the corresponding field metadata toMORPH_RELATIONwith a sharedmorphId. On the frontend, attachment read/write paths now switch totarget*Idwhen the flag is enabled.It also fixes optimistic filtering for morph join columns. The metadata API deduplicates morph fields, so attachments now expose a single target field of type
MORPH_RELATIONplus amorphRelationsarray listing each target object. Because only onesettings.joinColumnNameis returned (e.g.targetRocketId), filters liketargetCompanyIddon’t map to any field and the optimistic cache code throws.doesMorphRelationJoinColumnMatchresolves this by computing all valid join column names frommorphRelationsusingcomputeMorphRelationFieldNameand comparing them to the filter key. That makes filters liketargetCompanyIdresolvable even with a single target field, so attachment uploads and list matching no longer crash.Today the metadata API returns one morph field called
targetand a list of possible targets (morphRelations), but it does not tell us the join column for each target. That’s why the Frontend had to compute join column names.If we want to fix this at the API level, there are two options:
morphRelations(e.g. company →targetCompanyId). This is additive and low‑risk.targetCompany,targetPerson, etc.) instead of a single target. This is a larger change because it changes the shape of metadata and would require more UI updates.