twentyhq/twenty · error · Error

Failed to delete message.direction field for workspace ${wor

Error message

Failed to delete message.direction field for workspace ${workspaceId}

What it means

Thrown by the 2.3 command that drops the message.direction field. It submits a field-metadata delete operation through validateBuildAndRunLegacyWorkspaceMigration; on status === 'fail' it logs the report and throws. The report shows why the field deletion could not be built/applied.

Source

Thrown at packages/twenty-server/src/database/commands/upgrade-version-command/2-3/2-3-workspace-command-1777400000000-drop-message-direction-field.command.ts:95

          allFlatEntityOperationByMetadataName: {
            fieldMetadata: {
              flatEntityToCreate: [],
              flatEntityToDelete: [directionFieldMetadata],
              flatEntityToUpdate: [],
            },
          },
          workspaceId,
          applicationUniversalIdentifier:
            twentyStandardFlatApplication.universalIdentifier,
        },
      );

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

      throw new Error(
        `Failed to delete message.direction field for workspace ${workspaceId}`,
      );
    }

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

View on GitHub (pinned to 1f5dd2bbd2)

Solutions

Read the logged JSON report to identify the blocking dependency (view/view-field/relation).
Remove or update the dependent view/relation rows for message.direction, then re-run.
If the field is already gone at metadata level, mark the workspace as upgraded for this command and clear any orphaned column manually.

Defensive patterns

Strategy: validation

Validate before calling

// Before running, confirm no view/view-field still references message.direction:
const dependents = Object.values(flatViewFieldMaps.byId).filter(vf => vf.fieldMetadataUniversalIdentifier === MESSAGE_DIRECTION_UI);
if (dependents.length > 0) { /* drop or reassign them first */ }

Try / catch

try {
  await command.runOnWorkspace({ workspaceId, options });
} catch (e) {
  logger.error({ workspaceId, err: e.message }, 'message.direction drop failed');
}

Prevention

Remove dependent views/relations on a field before its drop command runs.
On partial failure, clear orphaned columns/indices manually before retrying.

When it happens

Trigger: The message.direction field is referenced by a view, view-field, or relation that still exists (cascade delete blocked); the field's column cannot be dropped because a constraint/index depends on it; the field universalIdentifier no longer resolves because it was already removed in a prior run.

Common situations: A prior interrupted 2.3 run deleted the metadata but not the dependent view/relation; a custom view built on message.direction prevents the drop; DB-level index/constraint left over from an old schema.

Related errors

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