feature/email-reminders

[arpandhakal]

Changes

• All changes regarding the Tasks Improved Email Notifications - Reminder Emails goes here.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
tasks-app	Ready	Preview, Comment	May 28, 2026 2:30pm

[greptile-apps]

Greptile Summary

This PR introduces a task email reminder system: a new TaskReminderSents table to deduplicate sent reminders, a raw-SQL eligibility query that identifies tasks needing reminders today, and a getReminderEmailDetails helper that generates email copy for all six reminder types.

• Schema & migration (taskReminderSent.prisma, migration.sql): adds the TaskReminderSents table with a (taskId, recipientId, reminderType) unique constraint as the idempotency primitive, and a CASCADE DELETE FK on taskId.
• Eligibility query (eligibility.ts): raw SQL that joins Tasks against itself to suppress same-assignee subtask duplicates and date-windows eligible tasks; the regex guard for malformed VARCHAR(10) dueDate values is structurally unsafe — it sits in a separate AND condition from the ::date cast, leaving the cast unprotected against planner reordering.
• Email copy (notification.helpers.ts): getReminderEmailDetails covers all six TaskReminderType variants with workspace-branded subjects and workspace-label-driven headers; the NO_DUE_DATE bodies still use "assigned to you" for company recipients, contradicting the correct company-specific header.

Confidence Score: 3/5

The eligibility query's dueDate cast guard is structurally incorrect — a single malformed row in the Tasks table could cause the entire daily cron run to throw a PostgreSQL cast error, silently skipping all reminders for that day.

The developer explicitly documented the risk of malformed VARCHAR dueDate values poisoning the query, but the chosen mitigation (a separate AND condition) does not guarantee evaluation order in PostgreSQL. If any task row contains a dueDate that passes the regex format check but fails the ::date cast (e.g. '2023-13-99'), or if the planner evaluates the cast condition before the regex, the entire getEligibleReminders call fails and no reminders go out that day. This is the critical path of the new feature and would be completely silent in normal monitoring.

src/jobs/notifications/eligibility.ts — the WHERE clause combining the regex guard and the ::date cast needs the most attention before merge.

Important Files Changed

Filename	Overview
src/jobs/notifications/eligibility.ts	Introduces getEligibleReminders with a raw SQL query; the regex guard for malformed VARCHAR dueDate is in a separate AND condition from the cast, so PostgreSQL's planner may attempt the cast before the guard fires.
src/app/api/notification/notification.helpers.ts	Adds getReminderEmailDetails; NO_DUE_DATE body text uses "assigned to you" for both individual and company recipients, inconsistent with the company-specific header.
prisma/migrations/20260515091539_add_task_reminder_sents_table/migration.sql	Creates TaskReminderSents table with a unique constraint on (taskId, recipientId, reminderType) and a CASCADE DELETE FK on taskId; schema looks correct.
prisma/schema/taskReminderSent.prisma	New TaskReminderSent model with correct unique composite key and CASCADE delete from Task; looks correct.
prisma/schema/task.prisma	Adds the taskReminderSents relation to the Task model; minimal, correct change.
src/jobs/notifications/eligibility.test.ts	Good coverage of happy path, empty results, call count, and error propagation.
src/app/api/notification/notification.helpers.test.ts	Solid snapshot + behavioral tests covering all reminder types, custom labels, missing brandName, and ctaParams.
src/app/api/notification/snapshots/notification.helpers.test.ts.snap	Auto-generated snapshot file; reflects the current (inconsistent) body text for company recipients.

Sequence Diagram

sequenceDiagram
    participant Cron as Cron Job
    participant Eligibility as getEligibleReminders
    participant DB as PostgreSQL (Tasks / TaskReminderSents)
    participant Helper as getReminderEmailDetails
    participant Email as Email Service

    Cron->>Eligibility: getEligibleReminders(db)
    Eligibility->>DB: $queryRaw — SELECT eligible (task, assignee, reminderType) rows
    DB-->>Eligibility: EligibilityRow[]
    Eligibility-->>Cron: EligibilityRow[]

    loop For each EligibilityRow
        Cron->>Helper: getReminderEmailDetails(workspace, task, isCompanyRecipient)
        Helper-->>Cron: email content keyed by TaskReminderType
        Cron->>Email: Send reminder email (subject, header, body, ctaParams)
        Cron->>DB: INSERT INTO TaskReminderSents (taskId, recipientId, reminderType) ON CONFLICT DO NOTHING
    end

Loading

_{Reviews (1): Last reviewed commit: "Merge pull request #1236 from assemblyco..." | Re-trigger Greptile}

[greptile-apps]

The regex guard and the ::date cast are in two separate AND conditions. PostgreSQL's query planner is free to reorder AND predicates, so it can attempt t."dueDate"::date on a malformed value before the regex check has filtered it out, throwing a cast error that poisons the entire query for that day. The developer's comment confirms this risk is known; the fix is to use a CASE WHEN expression, which PostgreSQL guarantees evaluates sequentially and short-circuits.

Suggested change

	-- Guard against malformed VARCHAR(10) dueDate values: only cast when the string
	-- looks like ISO YYYY-MM-DD. Without this, a single bad row poisons the whole query.
	AND (t."dueDate" IS NULL OR t."dueDate" ~ '^[0-9]{4}-[0-9]{2}-[0-9]{2}$')
	AND (
	(t."dueDate" IS NULL AND t."assignedAt"::date IN (CURRENT_DATE - 3, CURRENT_DATE - 7))
	OR t."dueDate"::date IN (CURRENT_DATE - 7, CURRENT_DATE - 3, CURRENT_DATE, CURRENT_DATE + 3)
	)
	-- Guard against malformed VARCHAR(10) dueDate values: use CASE WHEN to guarantee
	-- the regex is evaluated before the ::date cast (AND predicate order is not guaranteed).
	AND (
	(t."dueDate" IS NULL AND t."assignedAt"::date IN (CURRENT_DATE - 3, CURRENT_DATE - 7))
	OR (CASE WHEN t."dueDate" ~ '^[0-9]{4}-[0-9]{2}-[0-9]{2}$'
	THEN t."dueDate"::date IN (CURRENT_DATE - 7, CURRENT_DATE - 3, CURRENT_DATE, CURRENT_DATE + 3)
	ELSE FALSE END)
	)

[greptile-apps]

NO_DUE_DATE bodies say "assigned to you" for company recipients

The NO_DUE_DATE_3D and NO_DUE_DATE_7D bodies hard-code the phrase "assigned to you" regardless of isCompanyRecipient. When a company is the assignee and isCompanyRecipient=true, the header correctly reads "A task was assigned to your company" but the body still says "assigned to you", sending an inconsistent message to recipients of company tasks. Adding a derived phrase — e.g. const assignedTo = isCompanyRecipient ? 'your ' + labels.groupTerm : 'you' — and using it in both NO_DUE_DATE bodies would align them with the already-correct header logic.

[vercel]

Deployment failed with the following error:

Deploying Serverless Functions to multiple regions is restricted to the Pro and Enterprise plans.

Learn More: https://vercel.link/multiple-function-regions