https://sonarly.com/issue/3104?type=bug
The CronTriggerCronJob iterates over all active workspaces without per-iteration error handling. A single query timeout aborts the entire cron run, preventing all remaining workspaces from having their cron-triggered logic functions checked.
Fix: The fix adds per-workspace error isolation to `CronTriggerCronJob.handle()` by wrapping the loop body in a `try-catch`, exactly matching the pattern already used in every other workspace-iterating cron job (e.g. `WorkflowCronTriggerCronJob`).
Two additions were made to the class:
1. A `Logger` instance (`private readonly logger = new Logger(CronTriggerCronJob.name)`) for structured error logging.
2. An injected `ExceptionHandlerService` (globally provided via `@Global()` `ExceptionHandlerModule`) for Sentry/exception reporting.
The `try-catch` block isolates each workspace iteration so that a query timeout on one workspace (e.g. from connection-pool contention) is caught, logged, and reported — without aborting processing for the remaining workspaces.
```typescript file=packages/twenty-server/src/engine/core-modules/logic-function/logic-function-trigger/triggers/cron/cron-trigger.cron.job.ts lines=51-95
for (const activeWorkspace of activeWorkspaces) {
try {
const logicFunctionsWithCronTrigger =
await this.logicFunctionRepository.find({ ... });
// ... inner loop unchanged
} catch (error) {
this.logger.error(
`Error processing workspace ${activeWorkspace.id}: ${error}`,
);
this.exceptionHandlerService.captureExceptions([error], {
workspace: { id: activeWorkspace.id },
});
}
}
```
No module changes are required because `ExceptionHandlerModule` is decorated with `@Global()` and exports `ExceptionHandlerService` globally.
Sonarly Claude Code
f4fdf3384d