SMS workflow reminder retry count tracking

[everettbu]

Test 9

[greptile-apps]

Greptile Summary

This PR implements SMS workflow reminder retry count tracking for the Cal.com application. The changes add infrastructure to track failed SMS delivery attempts and implement cleanup logic to prevent infinite retry loops.

The implementation consists of three main components:

1. Database Schema Changes: A new retryCount field is added to the WorkflowReminder model in the Prisma schema with a default value of 0. This allows the system to persist retry attempt counts across multiple cron job executions.

2. Database Migration: A corresponding migration file adds the retryCount column to the existing WorkflowReminder table with appropriate constraints (INTEGER NOT NULL DEFAULT 0).

3. API Logic Updates: The scheduleSMSReminders.ts file is modified to include retry tracking functionality. The system now increments the retryCount when SMS scheduling fails or encounters errors, and includes cleanup logic to delete reminders that have exceeded the retry threshold.

This change integrates with Cal.com's existing workflow reminder system, which handles automated SMS notifications for booking events. The retry mechanism ensures that temporary SMS delivery failures (such as Twilio API issues or network problems) don't result in permanently lost notifications, while also preventing infinite retry attempts that could overwhelm the system.

Confidence score: 2/5

• This PR has significant logical issues that could cause production problems if merged
• The cleanup logic deletes reminders after only 1 retry attempt (retryCount > 1), which may be too aggressive and could result in legitimate reminders being discarded prematurely
• The scheduleSMSReminders.ts file needs careful review due to potential retry logic flaws and missing maximum retry limits

_{3 files reviewed, 2 comments}

_{Edit Code Review Bot Settings | Greptile}

[greptile-apps]

logic: This condition deletes reminders with retryCount > 1, meaning reminders are deleted after just one retry attempt. This seems too aggressive - consider if this should be a higher threshold like > 3 or > 5 to allow multiple retry attempts.

[greptile-apps]

logic: No maximum retry limit is enforced. Without a cap (e.g., retryCount < 5), reminders could be retried indefinitely, potentially causing performance issues over time.

[github-actions]

Hey there and thank you for opening this pull request! 👋🏼

We require pull request titles to follow the Conventional Commits specification and it looks like your proposed title needs to be adjusted.

Details:

No release type found in pull request title "SMS workflow reminder retry count tracking". Add a prefix to indicate what kind of release this pull request corresponds to. For reference, see https://www.conventionalcommits.org/

Available types:
 - feat: A new feature
 - fix: A bug fix
 - docs: Documentation only changes
 - style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
 - refactor: A code change that neither fixes a bug nor adds a feature
 - perf: A code change that improves performance
 - test: Adding missing tests or correcting existing tests
 - build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
 - ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
 - chore: Other changes that don't modify src or test files
 - revert: Reverts a previous commit

[github-actions]

This PR is being marked as stale due to inactivity.