https://sonarly.com/issue/3797?type=bug
The `WorkflowHandleStaledRunsWorkspaceService.handleStaledRunsForWorkspace()` fetches all staled workflow runs without a limit and passes all IDs to a single `update()` call, which hits the ORM's hard 200-record update limit, preventing recovery of stuck workflow runs.
Fix: Replaced the unbounded `find()` + single `update()` pattern with a batched do-while loop that processes staled workflow runs in chunks of `QUERY_MAX_RECORDS` (200).
**What changed:**
- Added `import { QUERY_MAX_RECORDS } from 'twenty-shared/constants'` (same import used by sibling `workflow-run-enqueue.workspace-service.ts`)
- Changed the `find()` call to include `select: { id: true }` and `take: QUERY_MAX_RECORDS` to limit each batch to 200 records
- Wrapped the find+update in a `do-while` loop that continues fetching and updating batches until fewer than `QUERY_MAX_RECORDS` are returned (meaning all staled runs have been processed)
- Added a guard so `recomputeWorkflowRunNotStartedCount` is only called if at least one record was updated
**Why this works:**
Each batch updates at most 200 records, staying within the `WorkspaceUpdateQueryBuilder`'s `QUERY_MAX_RECORDS` limit. After each batch is updated (status changed from `ENQUEUED` → `NOT_STARTED`), those records no longer match `getStaledRunsFindOptions()`, so the next `find()` naturally returns the next set of staled runs. This is the same pattern used by `workflow-run-enqueue.workspace-service.ts` (lines 83-98) which already works correctly in production.
Sonarly Claude Code
ede012f9ba