Fix viewField delete migration failure during field deactivation

When a field is deactivated, both views and their viewFields are scheduled for deletion. Since view.delete actions run before viewField.delete actions in the migration runner, and the DB CASCADE on viewField.viewId already removes viewFields when their parent view is deleted, the explicit viewField delete actions are redundant. Under concurrent workspace operations, a cache race condition between the builder and runner phases causes the runner to not find the viewField by universal identifier, throwing "Migration action 'delete' for 'viewField' failed". Filter out viewFields and viewFilters belonging to views being deleted, since the DB CASCADE handles their removal automatically. Co-Authored-By: Claude Opus 4.6 <[email protected]>
2026-02-19 10:33:51 +00:00
1 changed files with 17 additions and 2 deletions
@@ -99,10 +99,25 @@ export const handleFieldMetadataDeactivationSideEffects = ({
    kanbanAggregateOperationFieldMetadataUniversalIdentifier: null,
  }));

+  // Filter out viewFields and viewFilters belonging to views that are being
+  // deleted. The DB CASCADE on the viewId FK will automatically remove them
+  // when the view is deleted, so explicit delete actions are redundant.
+  // Including them can cause race-condition failures when the runner's cache
+  // no longer contains the viewField/viewFilter at transpilation time.
+  const viewIdsToDeleteSet = new Set(viewIdsToDelete);
+
+  const filteredFlatViewFieldsToDelete = flatViewFieldsToDelete.filter(
+    (viewField) => !viewIdsToDeleteSet.has(viewField.viewId),
+  );
+
+  const filteredFlatViewFiltersToDelete = flatViewFiltersToDelete.filter(
+    (viewFilter) => !viewIdsToDeleteSet.has(viewFilter.viewId),
+  );
+
  return {
    flatViewsToUpdate,
    flatViewsToDelete,
-    flatViewFieldsToDelete,
-    flatViewFiltersToDelete,
+    flatViewFieldsToDelete: filteredFlatViewFieldsToDelete,
+    flatViewFiltersToDelete: filteredFlatViewFiltersToDelete,
  };
 };