fix(tables): don't strand layout writes while views load, keep schema undos across views

Two more instances of layout being written without a known owner.

The sink was left unbound until a view resolved, so a resize/reorder/pin (or
the column-append effect) during the views fetch fell through to the table's
shared metadata — corrupting All for a table about to adopt a view, and losing
the edit to the re-seed. The sink is now bound while the query is in flight and
suppresses the write. An error counts as settled, so a failed views fetch falls
back to All instead of suppressing layout writes for the session.

Pruning was also too broad: create-column and delete-column are table-scoped
schema ops that merely have a layout side-effect, so dropping them on a view
switch made a deleted column unrecoverable. Only reorder-columns is purely
layout and still prunes; the other two survive and have just their layout half
suppressed at replay when the recorded view isn't active.

Author: TheodoreSpeaks

apps/sim/app/workspace/[workspaceId]/tables/[tableId]/table.tsx

@@ -358,7 +358,11 @@ export function Table({
     ((previousName: string, newName: string) => void) | null
   >(null)
 
-  const { data: views = NO_VIEWS, isSuccess: viewsLoaded } = useTableViews({
+  const {
+    data: views = NO_VIEWS,
+    isSuccess: viewsLoaded,
+    isError: viewsFailed,
+  } = useTableViews({
     workspaceId,
     tableId,
     enabled: viewsEnabled,
@@ -389,6 +393,12 @@ export function Table({
    *  rendering an empty view. */
   const activeView = activeViewId ? (views.find((view) => view.id === activeViewId) ?? null) : null
 
+  /** The views query hasn't settled, so which view owns the layout isn't known
+   *  yet and layout writes must go nowhere. An ERROR counts as settled: the table
+   *  falls back to All and writes resume against shared metadata, rather than
+   *  staying silently suppressed for the rest of the session. */
+  const viewOwnerUnknown = viewsEnabled && !viewsLoaded && !viewsFailed
+
   const [viewModal, setViewModal] = useState<ViewModalState>(null)
   /** Which view id the local filter/sort/hidden state was last seeded from.
    *  `undefined` means "nothing seeded yet" so the first resolve still runs. */
@@ -643,8 +653,10 @@ export function Table({
   /** Column order/width/pinning auto-saves into the active view as the user drags,
    *  which is why `isSameViewConfig` excludes layout from the dirty check. Sent as
    *  a `configPatch` so the server merges it — two overlapping layout writes must
-   *  not each replace the whole blob from their own snapshot. With no view active
-   *  the grid keeps writing the table's shared metadata. */
+   *  not each replace the whole blob from their own snapshot. With All selected
+   *  the sink is unbound and the grid writes the table's shared metadata instead;
+   *  while the views query is still loading the sink IS bound and the write is
+   *  suppressed, because the owner isn't known yet. */
   const handlePersistLayout = useCallback(
     (patch: TableMetadata) => {
       liveLayoutRef.current = { ...liveLayoutRef.current, ...patch }
@@ -1340,7 +1352,14 @@ export function Table({
         hiddenColumns={effectiveHiddenColumns}
         viewLayout={activeView?.config ?? null}
         viewLayoutKey={activeView?.id ?? null}
-        onPersistLayout={activeView ? handlePersistLayout : undefined}
+        onPersistLayout={
+          // While the views query is in flight the layout owner is unknown, so
+          // the sink is bound anyway: `handlePersistLayout` buffers into
+          // `liveLayoutRef` and suppresses the write. Leaving it unset would fall
+          // through to the table's shared metadata and corrupt All's layout for a
+          // table that is about to adopt a view.
+          viewOwnerUnknown || activeView ? handlePersistLayout : undefined
+        }
         columnRenameSinkRef={columnRenameSinkRef}
         afterDeleteRowsSinkRef={afterDeleteRowsSinkRef}
         afterDeleteAllSinkRef={afterDeleteAllSinkRef}

apps/sim/hooks/use-table-undo.ts

@@ -189,7 +189,12 @@ export function useTableUndo({
   )
 
   const executeAction = useCallback(
-    async (action: TableUndoAction, direction: 'undo' | 'redo') => {
+    async (action: TableUndoAction, direction: 'undo' | 'redo', entryViewId: string | null) => {
+      // Column create/delete are table-scoped, so they stay undoable after a view
+      // switch — but the layout they recorded belongs to the view that was active
+      // at the time. Replaying it elsewhere would write one view's order/widths
+      // into another, so the schema half runs and the layout half is dropped.
+      const entryOwnsLayout = entryViewId === activeViewIdRef.current
       try {
         switch (action.type) {
           case 'update-cell': {
@@ -338,7 +343,7 @@ export function useTableUndo({
                     metadata.pinnedColumns = newPinned
                   }
                   if (Object.keys(metadata).length > 0) {
-                    persistLayoutRef.current(metadata)
+                    if (entryOwnsLayout) persistLayoutRef.current(metadata)
                   }
                 },
               })
@@ -430,7 +435,7 @@ export function useTableUndo({
                       }
                     }
                     if (Object.keys(metadata).length > 0) {
-                      persistLayoutRef.current(metadata)
+                      if (entryOwnsLayout) persistLayoutRef.current(metadata)
                     }
                   },
                 }
@@ -459,7 +464,7 @@ export function useTableUndo({
                     }
                   }
                   if (Object.keys(metadata).length > 0) {
-                    persistLayoutRef.current(metadata)
+                    if (entryOwnsLayout) persistLayoutRef.current(metadata)
                   }
                 },
               })
@@ -521,6 +526,10 @@ export function useTableUndo({
                 ...restored.filter((n) => !pinnedSet.has(n)),
               ]
             }
+            // Pruning already drops these on a view switch, so a mismatch here
+            // should be unreachable; the guard keeps the invariant local rather
+            // than dependent on when the prune effect happens to run.
+            if (!entryOwnsLayout) break
             onColumnOrderChangeRef.current?.(order)
             persistLayoutRef.current({ columnOrder: order })
             break
@@ -546,7 +555,7 @@ export function useTableUndo({
     }
     const entry = popUndo(tableId)
     if (!entry) return
-    void runWithoutRecording(() => executeAction(entry.action, 'undo'))
+    void runWithoutRecording(() => executeAction(entry.action, 'undo', entry.viewId))
   }, [popUndo, tableId, executeAction])
 
   const redo = useCallback(() => {
@@ -560,7 +569,7 @@ export function useTableUndo({
     }
     const entry = popRedo(tableId)
     if (!entry) return
-    void runWithoutRecording(() => executeAction(entry.action, 'redo'))
+    void runWithoutRecording(() => executeAction(entry.action, 'redo', entry.viewId))
   }, [popRedo, tableId, executeAction])
 
   return { pushUndo, undo, redo, canUndo, canRedo }

apps/sim/stores/table/store.test.ts

@@ -12,6 +12,18 @@ const reorder: TableUndoAction = {
   previousOrder: ['a', 'b'],
   newOrder: ['b', 'a'],
 }
+const deleteColumn: TableUndoAction = {
+  type: 'delete-column',
+  columnName: 'a',
+  columnType: 'string',
+  columnPosition: 0,
+  columnUnique: false,
+  columnRequired: false,
+  cellData: [],
+  previousOrder: ['a', 'b'],
+  previousWidth: null,
+  previousPinnedColumns: null,
+}
 const updateCell: TableUndoAction = {
   type: 'update-cell',
   rowId: 'r1',
@@ -65,6 +77,19 @@ describe('pruneLayoutActions', () => {
     expect(useTableUndoStore.getState().stacks[TABLE]?.redo).toHaveLength(0)
   })
 
+  it('keeps column create/delete across a view switch — they are schema ops', () => {
+    const store = useTableUndoStore.getState()
+    store.push(TABLE, deleteColumn, 'view-a')
+
+    store.pruneLayoutActions(TABLE, 'view-b')
+
+    const undo = useTableUndoStore.getState().stacks[TABLE]?.undo
+    expect(undo).toHaveLength(1)
+    expect(undo?.[0].action.type).toBe('delete-column')
+    // Its recorded owner survives so the replay can drop just the layout half.
+    expect(undo?.[0].viewId).toBe('view-a')
+  })
+
   it('treats All (null) as its own owner', () => {
     const store = useTableUndoStore.getState()
     store.push(TABLE, reorder, null)

apps/sim/stores/table/store.ts

@@ -7,7 +7,7 @@ import { generateShortId } from '@sim/utils/id'
 import { create } from 'zustand'
 import { devtools } from 'zustand/middleware'
 import type { TableUndoAction, TableUndoStacks, TableUndoState, UndoEntry } from './types'
-import { LAYOUT_UNDO_ACTIONS } from './types'
+import { VIEW_SCOPED_UNDO_ACTIONS } from './types'
 
 const STACK_CAPACITY = 100
 const EMPTY_STACKS: TableUndoStacks = { undo: [], redo: [] }
@@ -192,7 +192,7 @@ export const useTableUndoStore = create<TableUndoState>()(
         const current = get().stacks[tableId]
         if (!current) return
         const owned = (entry: UndoEntry) =>
-          !LAYOUT_UNDO_ACTIONS.has(entry.action.type) || entry.viewId === viewId
+          !VIEW_SCOPED_UNDO_ACTIONS.has(entry.action.type) || entry.viewId === viewId
         const undo = current.undo.filter(owned)
         const redo = current.redo.filter(owned)
         if (undo.length === current.undo.length && redo.length === current.redo.length) return

apps/sim/stores/table/types.ts

@@ -90,21 +90,21 @@ export interface UndoEntry {
   /**
    * Active view when the action was recorded — `null` for "All" or when views
    * are disabled. Layout is view-owned, so a layout action is only meaningful
-   * against the view that owned it; see {@link LAYOUT_UNDO_ACTIONS}.
+   * against the view that owned it; see {@link VIEW_SCOPED_UNDO_ACTIONS}.
    */
   viewId: string | null
 }
 
 /**
- * Action types whose undo writes column layout (order, widths, pinning). These
- * are scoped to the view that was active when they were recorded; every other
- * action type operates on rows or the schema and is table-scoped.
+ * Action types that do NOTHING but rearrange columns, so they mean nothing
+ * outside the view that recorded them and are dropped on a view switch.
+ *
+ * Deliberately excludes `create-column`/`delete-column`: those are table-scoped
+ * schema operations that merely have a layout side-effect, so they stay
+ * undoable everywhere. Their layout half is suppressed at replay time instead —
+ * see `entryOwnsLayout` in `use-table-undo`.
  */
-export const LAYOUT_UNDO_ACTIONS = new Set<TableUndoAction['type']>([
-  'create-column',
-  'delete-column',
-  'reorder-columns',
-])
+export const VIEW_SCOPED_UNDO_ACTIONS = new Set<TableUndoAction['type']>(['reorder-columns'])
 
 export interface TableUndoStacks {
   undo: UndoEntry[]
@@ -120,8 +120,8 @@ export interface TableUndoState {
   patchUndoRowId: (tableId: string, oldRowId: string, newRowId: string) => void
   clear: (tableId: string) => void
   /**
-   * Drops layout actions recorded under a different view. Called on every view
-   * switch so undo can never write one view's layout into another.
+   * Drops purely-layout actions recorded under a different view. Called on every
+   * view switch so undo can never write one view's layout into another.
    */
   pruneLayoutActions: (tableId: string, viewId: string | null) => void
 }