You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
refactor(tables): make the atomic cell-merge the only row-write path
Audit of the opt-in-per-caller approach found it incomplete and the wrong shape:
- `replace` mode never actually replaces — updateRow computes mergedData =
{...existing, ...patch}, which only ever adds/overwrites keys, never deletes. So
replace is content-identical to patch and differs ONLY by being racy (full-object
read-modify-write = row-level last-write-wins). No caller benefits from it.
- Two structurally identical `data:{}` exec-clears in background/workflow-column-
execution.ts were left in replace mode, exposed to the same clobber the PR fixes.
- batchUpdateRows (the multi-cell grid/copilot path) still full-replaced with no
patch option at all, so the PR's own goal was only half-met.
Remove the dataWriteMode option entirely and make updateRow ALWAYS write the changed
cells via a shared jsonbMergePatch helper (data = data || {changed}::jsonb). Apply the
same helper per-row in batchUpdateRows. This auto-covers every updateRow caller —
including the two exec-clears — and closes the grid path, with the user-facing route
and copilot callers now unchanged vs staging (the fix lives entirely in the service
layer). computedWrite (the workflow-engine lock exemption) is untouched. Tests updated
to assert the always-on JSONB merge for both updateRow and batchUpdateRows.
0 commit comments