twentyhq/twenty · error · Error

Failed to delete CalendarEvent recordingPreference field for

Error message

Failed to delete CalendarEvent recordingPreference field for workspace ${workspaceId}

What it means

Thrown by the 2.14 command that drops the CalendarEvent.recordingPreference field when validateBuildAndRunLegacyWorkspaceMigration returns status 'fail' for the delete operation. The logger.error line above it prints the full validation result; the thrown error is workspace-scoped. A delete can fail validation when the field is referenced by other metadata (views, layouts, computed fields) that the validator refuses to leave dangling.

Source

Thrown at packages/twenty-server/src/database/commands/upgrade-version-command/2-14/2-14-workspace-command-1799000066000-drop-calendar-event-recording-preference.command.ts:100

              flatEntityToUpdate: [],
            },
          },
          workspaceId,
          applicationUniversalIdentifier:
            twentyStandardFlatApplication.universalIdentifier,
        },
      );

    if (validateAndBuildResult.status === 'fail') {
      this.logger.error(
        `Failed to delete CalendarEvent recordingPreference field:\n${JSON.stringify(
          validateAndBuildResult,
          null,
          2,
        )}`,
      );

      throw new Error(
        `Failed to delete CalendarEvent recordingPreference field for workspace ${workspaceId}`,
      );
    }

    this.logger.log(
      `Deleted CalendarEvent recordingPreference field for workspace ${workspaceId}`,
    );
  }
}

View on GitHub (pinned to 1f5dd2bbd2)

Solutions

Read the logger.error output immediately preceding the throw to see which references block the delete.
Remove or repoint the dependent viewField/pageLayout rows referencing recordingPreference, then re-run.
Verify the recordingPreference field still exists and is active before this command (the delete payload is built upstream); if already gone, the command should be a no-op.
Re-run the workspace upgrade after cleanup.

Defensive patterns

Strategy: validation

Validate before calling

// Confirm recordingPreference has no remaining references that would block delete.
const refs = await dataSource.query(`
  SELECT 'viewField' AS src, id FROM core."viewField" WHERE "fieldMetadataId" = $1
  UNION ALL
  SELECT 'pageLayoutField', id FROM core."pageLayoutField" WHERE "fieldMetadataId" = $1
`, [fieldId]);
if (refs.length) throw new Error(`recordingPreference still referenced: ${JSON.stringify(refs)}`);

Type guard

function isFailResult(r: unknown): r is { status: 'fail' } {
  return typeof r === 'object' && r !== null && (r as any).status === 'fail';
}

Try / catch

try {
  const res = await service.validateBuildAndRunLegacyWorkspaceMigration(payload);
  if (res.status === 'fail') throw new Error(`Failed to delete ... for workspace ${workspaceId}`);
} catch (err) { upgradeAudit.record(workspaceId, command.id, err); throw err; }

Prevention

Cascade or repoint viewField/pageLayout references before deleting a standard field.
Detect half-completed prior runs and clean up dangling references before re-running.

When it happens

Trigger: Running the 2.14 upgrade on a workspace where recordingPreference is still referenced by a viewField, pageLayout, or relation that the build phase cannot cascade-delete; or where the field was already partially removed leaving orphaned references.

Common situations: Custom objects/views built on top of recordingPreference; a prior failed run that deleted the view-field but not the fieldMetadata; metadata drift from manual DB edits.

Related errors

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