twentyhq/twenty · error · Error

Failed to create CallRecording standard objects for workspac

Error message

Failed to create CallRecording standard objects for workspace ${workspaceId}: ${JSON.stringify(validateAndBuildResult, null, 2)}

What it means

Thrown by the 2.10 CallRecording sync command after all collision renames succeed, when the final create migration for the new CallRecording standard objects/fields returns status 'fail'. The full validateAndBuildResult JSON is embedded in the message. This is the last step, so it leaves renames committed but the create unapplied.

Source

Thrown at packages/twenty-server/src/database/commands/upgrade-version-command/2-10/2-10-workspace-command-1799000055000-sync-call-recording-standard-objects.command.ts:540

            2,
          )}`,
        );
      }
    }

    const validateAndBuildResult =
      await this.workspaceMigrationValidateBuildAndRunService.validateBuildAndRunLegacyWorkspaceMigration(
        {
          isSystemBuild: true,
          applicationUniversalIdentifier:
            twentyStandardFlatApplication.universalIdentifier,
          workspaceId,
          allFlatEntityOperationByMetadataName,
        },
      );

    if (validateAndBuildResult.status === 'fail') {
      throw new Error(
        `Failed to create CallRecording standard objects for workspace ${workspaceId}: ${JSON.stringify(
          validateAndBuildResult,
          null,
          2,
        )}`,
      );
    }

    this.logger.log(
      `Applied ${totalOperationCount} CallRecording standard metadata operations for workspace ${workspaceId}`,
    );
  }
}

View on GitHub (pinned to 1f5dd2bbd2)

Solutions

Parse the validateAndBuildResult JSON embedded in the message for the precise create rejection.
Verify all collision renames actually committed for the failing workspace before retrying the create.
Recompute the workspace cache and re-run the command (it re-detects collisions idempotently).
Run --dryRun to confirm the planned operation count before committing.

Defensive patterns

Strategy: validation

Validate before calling

// Dry-run to preview total operation count; confirm renames are committed before the create runs:
await workspaceCacheService.invalidate(workspaceId);
const { flatObjectMetadataMaps } = await workspaceCacheService.getOrRecompute(workspaceId, ['flatObjectMetadataMaps']);
const stillColliding = findCallRecordingObjectNameCollisions(flatObjectMetadataMaps);
if (stillColliding.length > 0) throw new Error('Collisions still present; renames must commit before create');

Try / catch

// Parse the embedded validateAndBuildResult JSON to decide next action:
try {
  await command.runOnWorkspace({ workspaceId, options });
} catch (err) {
  const match = /Failed to create CallRecording standard objects[\s\S]*?(\{[\s\S]*\})/.exec(err.message);
  const result = match ? JSON.parse(match[1]) : null;
  logger.error(`CallRecording create failed for workspace ${workspaceId}`, result ?? err);
  failedWorkspaces.push(workspaceId);
}

Prevention

Verify all collision renames actually committed before the create step retries.
Run --dryRun to confirm the planned operation count.
Recompute the cache; the command re-detects collisions idempotently.
Parse the embedded validateAndBuildResult JSON before retrying.

When it happens

Trigger: Running the CallRecording create step on a workspace where renames committed but the new standard objects/fields batch is rejected — e.g. a residual name collision the rename missed, a missing parent object, or a duplicate universal identifier.

Common situations: Rename step partially succeeded leaving a name still colliding; stale cache; a prior aborted run already created some CallRecording entities (duplicates); standard CallRecording metadata version mismatch with the workspace.

Related errors

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