https://sonarly.com/issue/3806?type=bug
A race condition between concurrent calendar sync jobs causes a foreign key violation when inserting `calendarChannelEventAssociation` records. A concurrent hard-delete by the calendar event cleaner removes referenced `calendarEvent` rows between the find and insert within the same transaction, causing a PostgreSQL FK violation (23503) wrapped as a generic "Data validation error."
Fix: **Problem**: When a PostgreSQL foreign key violation (code `23503`) occurs during `calendarChannelEventAssociation` INSERT — caused by a race condition with the concurrent calendar event cleaner hard-deleting referenced events — the `PostgresException` with code `'23503'` doesn't match any recognized exception code in the calendar error handler's switch statement. It falls to the `default` case, which permanently marks the calendar channel as `FAILED_UNKNOWN`, stopping sync entirely.
**Fix**: Added `POSTGRESQL_ERROR_CODES.FOREIGN_KEY_VIOLATION` (`'23503'`) as a case in the `handleDriverException` switch statement, routing it to `handleTemporaryException`. This treats FK violations as transient errors (which they are — caused by a concurrent cleanup race), enabling retry with exponential backoff via the existing `throttleFailureCount` mechanism. On retry, the `find()` query will see the current database state and the race condition is unlikely to recur.
This follows the existing pattern where `TwentyORMExceptionCode.QUERY_READ_TIMEOUT` is also routed to `handleTemporaryException`.
Sonarly Claude Code
5843d1d4cd