twentyhq/twenty · error · Error
Failed to rename conflicting custom fields for workspace ${w
Error message
Failed to rename conflicting custom fields for workspace ${workspaceId} What it means
Thrown by the 2.10 workspace upgrade command when validateBuildAndRunLegacyWorkspaceMigration returns 'fail' while renaming a pre-existing custom field whose name collides with a new generic standard field (Company.annualRevenue). Renames run per-application with isSystemBuild:true; a failure aborts the whole workspace batch.
Source
Thrown at packages/twenty-server/src/database/commands/upgrade-version-command/2-10/2-10-workspace-command-1799000045000-rename-conflicting-custom-fields.command.ts:186
allFlatEntityOperationByMetadataName: {
fieldMetadata: {
flatEntityToCreate: [],
flatEntityToDelete: [],
flatEntityToUpdate,
},
},
workspaceId,
isSystemBuild: true,
applicationUniversalIdentifier,
},
);
if (validateAndBuildResult.status === 'fail') {
this.logger.error(
`Failed to rename conflicting custom fields:\n${JSON.stringify(validateAndBuildResult, null, 2)}`,
);
throw new Error(
`Failed to rename conflicting custom fields for workspace ${workspaceId}`,
);
}
}
this.logger.log(
`Renamed ${fieldsToRename.length} conflicting custom field(s) for workspace ${workspaceId}`,
);
}
}
View on GitHub (pinned to 1f5dd2bbd2)
Solutions
- Read the logged validateAndBuildResult JSON to see which rename was rejected and why.
- Check the Company object in the failing workspace for existing 'annualRevenueCustom*' names blocking the computed candidate.
- Recompute the workspace cache and re-run so the taken-name set is accurate.
- Run --dryRun to preview the computed new names before committing.
Defensive patterns
Strategy: validation
Validate before calling
// Dry-run to preview computed rename names, and confirm no 'annualRevenueCustom*' names already block candidates:
await workspaceCacheService.invalidate(workspaceId);
const { flatFieldMetadataMaps } = await workspaceCacheService.getOrRecompute(workspaceId, ['flatFieldMetadataMaps']);
const companyFields = Object.values(flatFieldMetadataMaps.byUniversalIdentifier).filter((f) => isDefined(f) && f.objectMetadataUniversalIdentifier === STANDARD_OBJECTS.company.universalIdentifier);
const blocking = companyFields.filter((f) => /^annualRevenueCustom\d*$/.test(f.name));
if (blocking.length > 0) throw new Error(`Existing names block rename: ${blocking.map((f) => f.name).join(', ')}`); Try / catch
try {
await command.runOnWorkspace({ workspaceId, options });
} catch (err) {
logger.error(`Conflicting custom field rename failed for workspace ${workspaceId}`, err);
failedWorkspaces.push(workspaceId);
} Prevention
- Run --dryRun to preview the computed new field names.
- Check the Company object for pre-existing 'annualRevenueCustom*' names that consume candidates.
- Recompute the cache so the taken-name set is accurate.
- Catch per-workspace at the runner.
When it happens
Trigger: Running the 2.10 conflicting-field rename on a workspace that has a custom 'annualRevenue' field on Company, but the computed replacement name (annualRevenueCustom / annualRevenueCustom2 ...) itself collides, or the field metadata update is rejected by the builder.
Common situations: Workspace already has fields named annualRevenueCustom, annualRevenueCustom2, etc. consuming candidates; the conflicting field is non-custom (the command warns and skips, but a stale cache can misclassify); rename target violates field-name validation rules.
Related errors
- Failed to rename CallRecording name collision for workspace
- Failed to create inactive generic standard fields for worksp
- Could not find an available callRecordingOld name after ${MA
- Could not find an available ${originalFieldName}Old name aft
- Failed to update search command menu item labels for workspa
AI-assisted analysis of twentyhq/twenty@1f5dd2bbd2 (2026-08-12).
Data as JSON: /api/errors/7866c9caefa0d10b.
Report an issue: GitHub.