Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 35 additions & 6 deletions packages/features/ee/workflows/api/scheduleSMSReminders.ts
Original file line number Diff line number Diff line change
Expand Up @@ -28,10 +28,19 @@ async function handler(req: NextApiRequest, res: NextApiResponse) {
//delete all scheduled sms reminders where scheduled date is past current date
await prisma.workflowReminder.deleteMany({
where: {
method: WorkflowMethods.SMS,
scheduledDate: {
lte: dayjs().toISOString(),
},
OR: [
{
method: WorkflowMethods.SMS,
scheduledDate: {
lte: dayjs().toISOString(),
},
},
{
retryCount: {
gt: 1,
},
},
],
},
});

Expand All @@ -44,8 +53,11 @@ async function handler(req: NextApiRequest, res: NextApiResponse) {
lte: dayjs().add(7, "day").toISOString(),
},
},
select,
})) as PartialWorkflowReminder[];
select: {
...select,
retryCount: true,
},
})) as (PartialWorkflowReminder & { retryCount: number })[];

if (!unscheduledReminders.length) {
res.json({ ok: true });
Expand Down Expand Up @@ -163,9 +175,26 @@ async function handler(req: NextApiRequest, res: NextApiResponse) {
referenceId: scheduledSMS.sid,
},
});
} else {
await prisma.workflowReminder.update({
where: {
id: reminder.id,
},
data: {
retryCount: reminder.retryCount + 1,

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestion: Incrementing the retry counter using retryCount: reminder.retryCount + 1 is a non-atomic read-modify-write that can lose increments when multiple cron executions overlap, so this should use Prisma's atomic increment operation to be concurrency-safe. [race condition]

Severity Level: Major ⚠️
- ⚠️ Lost increments under concurrent cron executions.
- ❌ SMS retry limit enforcement becomes inaccurate.
- ⚠️ Affects POST /api/cron/workflows/scheduleSMSReminders endpoint.
Suggested change
retryCount: reminder.retryCount + 1,
retryCount: {
increment: 1,
},
Steps of Reproduction ✅
1. The cron endpoint `/api/cron/workflows/scheduleSMSReminders` is implemented by
`handler` in `packages/features/ee/workflows/api/scheduleSMSReminders.ts:21-202` and
exported via `apps/web/pages/api/cron/workflows/scheduleSMSReminders.ts:1`.

2. On each POST, the handler loads unscheduled SMS reminders via
`prisma.workflowReminder.findMany` at `scheduleSMSReminders.ts:47-60` (filtering by
`method: WorkflowMethods.SMS`, `scheduled: false`, and `scheduledDate`), then loops over
them and calls `twilio.scheduleSMS` at lines 158-166.

3. When `twilio.scheduleSMS` resolves to a falsy value without throwing (e.g. transient
failure where the provider returns no SID), execution enters the `else` block at
`scheduleSMSReminders.ts:168-187`, which updates the row using `data: { retryCount:
reminder.retryCount + 1 }`.

4. If the cron endpoint is invoked concurrently on multiple app instances (or re-invoked
before the previous run finishes) so that two handlers load the same reminder (both
reading `retryCount = 0` from the `findMany` at lines 47-60) and both experience the same
non-throwing failure, then both `update` calls in the `else` block race: each computes
`retryCount: 0 + 1` and writes `1`, resulting in only a single increment being persisted
instead of two. Because cleanup logic at `scheduleSMSReminders.ts:28-44` deletes reminders
only when `retryCount > 1`, this lost increment can cause more send attempts than intended
before the reminder is cleaned up.
Prompt for AI Agent 🤖
This is a comment left during a code review.

**Path:** packages/features/ee/workflows/api/scheduleSMSReminders.ts
**Line:** 184:184
**Comment:**
	*Race Condition: Incrementing the retry counter using `retryCount: reminder.retryCount + 1` is a non-atomic read-modify-write that can lose increments when multiple cron executions overlap, so this should use Prisma's atomic `increment` operation to be concurrency-safe.

Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
👍 | 👎

},
});
}
}
} catch (error) {
await prisma.workflowReminder.update({
where: {
id: reminder.id,
},
data: {
retryCount: reminder.retryCount + 1,

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestion: The retry counter increment in the error handler also uses retryCount: reminder.retryCount + 1, which can drop increments under concurrent runs of the cron job, so it should likewise use an atomic increment to ensure retries are counted correctly. [race condition]

Severity Level: Major ⚠️
- ⚠️ Retry counts inaccurate when provider errors occur.
- ❌ SMS reminders may exceed intended maximum retry attempts.
- ⚠️ Affects POST /api/cron/workflows/scheduleSMSReminders endpoint.
Suggested change
retryCount: reminder.retryCount + 1,
retryCount: {
increment: 1,
},
Steps of Reproduction ✅
1. The same cron handler in
`packages/features/ee/workflows/api/scheduleSMSReminders.ts:21-202` iterates over
unscheduled SMS reminders and calls `twilio.scheduleSMS` (lines 158-166); if this call
throws (e.g. network error), execution jumps to the `catch` block at lines 189-198.

2. In the `catch` block, the reminder's `retryCount` is updated via
`prisma.workflowReminder.update` with `data: { retryCount: reminder.retryCount + 1 }` at
`scheduleSMSReminders.ts:190-197`, using the `retryCount` value that was originally read
in the `findMany` at lines 47-60.

3. If two instances of the cron endpoint `/api/cron/workflows/scheduleSMSReminders` run
concurrently and both load the same reminder (each seeing the same `retryCount` value from
`findMany`) and both encounter a thrown error from `twilio.scheduleSMS`, they will each
execute the `catch` block and issue concurrent `update` statements writing `retryCount` to
the same computed value (e.g. both write `1` instead of incrementing from `0` to `2`).

4. Because cleanup at `scheduleSMSReminders.ts:28-44` relies on `retryCount > 1` to stop
retrying and delete reminders, these lost increments from the non-atomic `retryCount:
reminder.retryCount + 1` in the `catch` block can allow additional unintended retry
attempts or leave reminders in the system longer than the intended maximum number of
failures.
Prompt for AI Agent 🤖
This is a comment left during a code review.

**Path:** packages/features/ee/workflows/api/scheduleSMSReminders.ts
**Line:** 195:195
**Comment:**
	*Race Condition: The retry counter increment in the error handler also uses `retryCount: reminder.retryCount + 1`, which can drop increments under concurrent runs of the cron job, so it should likewise use an atomic `increment` to ensure retries are counted correctly.

Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
👍 | 👎

},
});
console.log(`Error scheduling SMS with error ${error}`);
}
}
Expand Down
Original file line number Diff line number Diff line change
@@ -0,0 +1,2 @@
-- AlterTable
ALTER TABLE "WorkflowReminder" ADD COLUMN "retryCount" INTEGER NOT NULL DEFAULT 0;
1 change: 1 addition & 0 deletions packages/prisma/schema.prisma
Original file line number Diff line number Diff line change
Expand Up @@ -997,6 +997,7 @@ model WorkflowReminder {
cancelled Boolean?
seatReferenceId String?
isMandatoryReminder Boolean? @default(false)
retryCount Int @default(0)

@@index([bookingUid])
@@index([workflowStepId])
Expand Down