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

  1. Read the logged validateAndBuildResult JSON to see which rename was rejected and why.
  2. Check the Company object in the failing workspace for existing 'annualRevenueCustom*' names blocking the computed candidate.
  3. Recompute the workspace cache and re-run so the taken-name set is accurate.
  4. 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

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


AI-assisted analysis of twentyhq/twenty@1f5dd2bbd2 (2026-08-12). Data as JSON: /api/errors/7866c9caefa0d10b. Report an issue: GitHub.