https://sonarly.com/issue/17389?type=bug
A race condition between two competing effects writing to the same context store atom causes bulk updates in Kanban view to target all workspace records instead of only the selected ones, triggering thousands of unintended webhook events and data mutations.
Fix: Two changes fix the race condition where Kanban bulk edit updates all records instead of selected ones:
**1. RecordIndexContainer.tsx — Render `RecordIndexFiltersToContextStoreEffect` only on Table view (line 66)**
The effect was mounted unconditionally, causing it to write table row selection (always `[]` on Kanban) to the same `contextStoreTargetedRecordsRuleComponentState` atom that `RecordBoardSelectRecordsEffect` writes board card selection to. Background events (SSE sync, cache updates) caused the `syncWriteAtom` to recreate due to unstable array references from `selectedRowIdsComponentSelector`, triggering the cleanup which reset the selection to `{ mode: 'selection', selectedRecordIds: [] }` — wiping the board's card selection.
By only rendering this effect when `recordIndexViewType === ViewType.TABLE`, the race condition is eliminated. Kanban and Calendar views manage their own selection via `RecordBoardSelectRecordsEffect` and equivalent effects.
**2. computeContextStoreFilters.ts — Return `undefined` for empty selection (defense in depth)**
Previously, when `selectedRecordIds` was `[]` in `selection` mode, the `id.in` filter was omitted, producing a filter that matched ALL records in the workspace. Now the function returns `undefined` early when `selectedRecordIds` is empty, treating "nothing selected" as "no records to operate on" rather than "all records." This is a safety net that prevents mass unintended updates even if a similar race condition were to occur in the future.
**3. Test added** for the empty selection edge case in `computeContextStoreFilters.test.ts`.
Sonarly Claude Code
3c590cb9fa