Conversation
- Introduced `getLabelsFromDb` to fetch label IDs for AWAITING_REPLY and TO_REPLY. - Updated `processAllFollowUpReminders` to use these labels for fetching threads. - Simplified thread processing logic and improved logging for better traceability. - Added tests for new label handling functions and ensured existing functionality remains intact.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📝 WalkthroughWalkthroughA follow-up reminders feature is introduced with a client-side settings UI, server-side batch processing logic, database schema extensions, API endpoints, server actions, and label/draft management utilities for automatically applying follow-up labels and generating drafts based on reply-status thresholds. Changes
Sequence DiagramssequenceDiagram
participant User as User
participant UI as Settings UI<br/>(FollowUpRemindersSetting)
participant Action as Server Action<br/>(updateFollowUpSettingsAction)
participant DB as Database<br/>(EmailAccount)
participant Provider as Email Provider
User->>UI: Configure follow-up days & auto-draft
UI->>Action: Call updateFollowUpSettingsAction
Action->>DB: Update followUpAwaitingReplyDays,<br/>followUpNeedsReplyDays,<br/>followUpAutoDraftEnabled
DB-->>Action: Success
Action-->>UI: Return result
UI->>User: Show success toast & close dialog
sequenceDiagram
participant Cron as Cron Job
participant API as follow-up-reminders<br/>API Endpoint
participant Processor as processAllFollowUpReminders
participant Account as processAccountFollowUps
participant DB as Database
participant Provider as Email Provider
participant Draft as generateFollowUpDraft
Cron->>API: GET /api/follow-up-reminders<br/>(with cron secret)
API->>Processor: Invoke processAllFollowUpReminders
Processor->>DB: Fetch premium accounts with<br/>follow-up thresholds
loop For each eligible account
Processor->>Account: Process account
Account->>DB: Get ThreadTracker entries<br/>past threshold
Account->>Provider: Get/create follow-up label
loop For each tracker (AWAITING, NEEDS_REPLY)
Account->>Provider: Apply follow-up label to message
Account->>DB: Update followUpAppliedAt
alt If auto-draft enabled
Account->>Draft: Generate follow-up draft
Draft->>Provider: Create draft email
end
end
Account->>Account: Cleanup stale drafts (7+ days old)
end
Processor-->>API: Return counts (total, success, errors)
API-->>Cron: Return results as JSON
sequenceDiagram
participant Inbound as Inbound Message<br/>Handler
participant Processor as process-history-item
participant LabelCleanup as clearFollowUpLabel
participant DB as Database
participant Provider as Email Provider
Inbound->>Processor: Handle inbound reply
Processor->>Processor: Main processing<br/>(detect reply, etc.)
Processor->>LabelCleanup: Clear follow-up label<br/>if reply detected
LabelCleanup->>DB: Query & reset followUpAppliedAt<br/>on ThreadTracker
LabelCleanup->>Provider: Remove follow-up label<br/>from thread
Provider-->>LabelCleanup: Label removed
LabelCleanup-->>Processor: Cleanup complete
Processor-->>Inbound: Processing done
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
5 issues found across 25 files
Prompt for AI agents (all issues)
Check if these issues are valid — if so, understand the root cause of each and fix them.
<file name="apps/web/utils/follow-up/labels.ts">
<violation number="1" location="apps/web/utils/follow-up/labels.ts:118">
P1: Database update occurs before label removal, creating potential inconsistency. If the email label removal fails (even silently due to try-catch in `removeFollowUpLabel`), the database will incorrectly show `followUpAppliedAt: null` while the label remains on the email. Consider checking if the label exists and can be removed before updating the database, or implement a retry mechanism with rollback on failure.</violation>
</file>
<file name="apps/web/utils/follow-up/cleanup.ts">
<violation number="1" location="apps/web/utils/follow-up/cleanup.ts:89">
P1: After successfully deleting stale drafts, the threadTracker records are never updated to mark them as resolved. This will cause the same trackers to be processed repeatedly on subsequent cleanup runs, leading to unnecessary API calls and potential errors when trying to delete already-deleted drafts.</violation>
</file>
<file name="apps/web/__tests__/e2e/flows/full-reply-cycle.test.ts">
<violation number="1" location="apps/web/__tests__/e2e/flows/full-reply-cycle.test.ts:163">
P1: Label verification is comparing database ID to label names array. For Outlook, `message.labelIds` contains category names, not database IDs. The assertion `expect(message.labelIds).toContain(labelAction.labelId)` will fail because `labelAction.labelId` is a database ID while `message.labelIds` contains label names. Need to fetch the label name from the database (as the removed code did) or use a helper that maps IDs to names.</violation>
<violation number="2" location="apps/web/__tests__/e2e/flows/full-reply-cycle.test.ts:293">
P1: Test may match emails from previous runs instead of current test. Changed from `initialEmail.fullSubject` (which includes unique run ID and sequence number) to hardcoded `"Thread continuity test"`. This removes the uniqueness guarantee and could cause `waitForMessageInInbox` to find stale emails from previous test runs, making the test flaky.</violation>
</file>
<file name="apps/web/utils/actions/follow-up-reminders.ts">
<violation number="1" location="apps/web/utils/actions/follow-up-reminders.ts:20">
P2: Add `revalidatePath()` after the database mutation to invalidate cached data. This ensures UI reflects the updated follow-up settings.</violation>
</file>
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
| if (!threadId) return; | ||
|
|
||
| try { | ||
| const { count } = await prisma.threadTracker.updateMany({ |
There was a problem hiding this comment.
P1: Database update occurs before label removal, creating potential inconsistency. If the email label removal fails (even silently due to try-catch in removeFollowUpLabel), the database will incorrectly show followUpAppliedAt: null while the label remains on the email. Consider checking if the label exists and can be removed before updating the database, or implement a retry mechanism with rollback on failure.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At apps/web/utils/follow-up/labels.ts, line 118:
<comment>Database update occurs before label removal, creating potential inconsistency. If the email label removal fails (even silently due to try-catch in `removeFollowUpLabel`), the database will incorrectly show `followUpAppliedAt: null` while the label remains on the email. Consider checking if the label exists and can be removed before updating the database, or implement a retry mechanism with rollback on failure.</comment>
<file context>
@@ -0,0 +1,144 @@
+ if (!threadId) return;
+
+ try {
+ const { count } = await prisma.threadTracker.updateMany({
+ where: {
+ emailAccountId,
</file context>
| @@ -0,0 +1,90 @@ | |||
| import { subDays } from "date-fns/subDays"; | |||
There was a problem hiding this comment.
P1: After successfully deleting stale drafts, the threadTracker records are never updated to mark them as resolved. This will cause the same trackers to be processed repeatedly on subsequent cleanup runs, leading to unnecessary API calls and potential errors when trying to delete already-deleted drafts.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At apps/web/utils/follow-up/cleanup.ts, line 89:
<comment>After successfully deleting stale drafts, the threadTracker records are never updated to mark them as resolved. This will cause the same trackers to be processed repeatedly on subsequent cleanup runs, leading to unnecessary API calls and potential errors when trying to delete already-deleted drafts.</comment>
<file context>
@@ -0,0 +1,90 @@
+ }
+ }
+
+ logger.info("Finished cleaning up stale drafts");
+}
</file context>
| const gmailReply = await waitForMessageInInbox({ | ||
| provider: gmail.emailProvider, | ||
| subjectContains: initialEmail.fullSubject, | ||
| subjectContains: "Thread continuity test", |
There was a problem hiding this comment.
P1: Test may match emails from previous runs instead of current test. Changed from initialEmail.fullSubject (which includes unique run ID and sequence number) to hardcoded "Thread continuity test". This removes the uniqueness guarantee and could cause waitForMessageInInbox to find stale emails from previous test runs, making the test flaky.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At apps/web/__tests__/e2e/flows/full-reply-cycle.test.ts, line 293:
<comment>Test may match emails from previous runs instead of current test. Changed from `initialEmail.fullSubject` (which includes unique run ID and sequence number) to hardcoded `"Thread continuity test"`. This removes the uniqueness guarantee and could cause `waitForMessageInInbox` to find stale emails from previous test runs, making the test flaky.</comment>
<file context>
@@ -302,10 +287,10 @@ describe.skipIf(!shouldRunFlowTests())("Full Reply Cycle", () => {
const gmailReply = await waitForMessageInInbox({
provider: gmail.emailProvider,
- subjectContains: initialEmail.fullSubject,
+ subjectContains: "Thread continuity test",
timeout: TIMEOUTS.EMAIL_DELIVERY,
});
</file context>
| subjectContains: "Thread continuity test", | |
| subjectContains: initialEmail.fullSubject, |
| messageLabels: message.labelIds, | ||
| }); | ||
| } | ||
| expect(message.labelIds).toContain(labelAction.labelId); |
There was a problem hiding this comment.
P1: Label verification is comparing database ID to label names array. For Outlook, message.labelIds contains category names, not database IDs. The assertion expect(message.labelIds).toContain(labelAction.labelId) will fail because labelAction.labelId is a database ID while message.labelIds contains label names. Need to fetch the label name from the database (as the removed code did) or use a helper that maps IDs to names.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At apps/web/__tests__/e2e/flows/full-reply-cycle.test.ts, line 163:
<comment>Label verification is comparing database ID to label names array. For Outlook, `message.labelIds` contains category names, not database IDs. The assertion `expect(message.labelIds).toContain(labelAction.labelId)` will fail because `labelAction.labelId` is a database ID while `message.labelIds` contains label names. Need to fetch the label name from the database (as the removed code did) or use a helper that maps IDs to names.</comment>
<file context>
@@ -157,26 +156,12 @@ describe.skipIf(!shouldRunFlowTests())("Full Reply Cycle", () => {
- messageLabels: message.labelIds,
- });
- }
+ expect(message.labelIds).toContain(labelAction.labelId);
+ logStep("Labels on message", { labels: message.labelIds });
}
</file context>
| await prisma.emailAccount.update({ | ||
| where: { id: emailAccountId }, | ||
| data: { followUpRemindersEnabled: enabled }, | ||
| }); |
There was a problem hiding this comment.
P2: Add revalidatePath() after the database mutation to invalidate cached data. This ensures UI reflects the updated follow-up settings.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At apps/web/utils/actions/follow-up-reminders.ts, line 20:
<comment>Add `revalidatePath()` after the database mutation to invalidate cached data. This ensures UI reflects the updated follow-up settings.</comment>
<file context>
@@ -0,0 +1,65 @@
+ await prisma.emailAccount.update({
+ where: { id: emailAccountId },
+ data: { followUpRemindersEnabled: enabled },
+ });
+ });
+
</file context>
There was a problem hiding this comment.
The follow-up form calls useForm<SaveFollowUpSettingsBody>({ defaultValues }) but never wires resolver: zodResolver(saveFollowUpSettingsBody), so RHF never enforces the same min/max constraints before submitting and users can enter negative/too-large day counts even though the server rejects them; per apps/web/CLAUDE.md the client form should use the matching Zod schema to keep validation in sync.
Prompt for AI Agents:
In apps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsx
around lines 132-136, the useForm call sets defaultValues but does not include a
resolver so client-side validation is not enforced against the server Zod schema. Import
zodResolver from @hookform/resolvers/zod and import the corresponding Zod schema (the
save follow-up settings schema) from utils/actions/follow-up-reminders.validation, then
change the useForm invocation to include resolver: zodResolver(<thatSchema>) alongside
defaultValues so RHF enforces the same min/max constraints as the server. Ensure the
imported schema name matches the exported name in the validation file and update imports
at the top of the file.
Finding type: AI Coding Guidelines
Heads up!
Your free trial ends in 2 days.
To keep getting your PRs reviewed by Baz, update your team's subscription
There was a problem hiding this comment.
The new daysSchema lets any number between 0.001 and 90 (and the UI uses step=0.001), so submitting a fractional day like 0.5 passes validation and is sent verbatim to the server. However the Prisma schema defines followUpAwaitingReplyDays/followUpNeedsReplyDays as Int, so updateFollowUpSettingsAction will now throw a validation error at save time whenever a non-integer day is entered. Either the schema or the validation/input constraints must be aligned before this change is merged.
| const daysSchema = z.number().min(0.001).max(90); | |
| export const saveFollowUpSettingsBody = z.object({ | |
| followUpAwaitingReplyDays: daysSchema, | |
| followUpNeedsReplyDays: daysSchema, | |
| followUpAutoDraftEnabled: z.boolean(), | |
| const daysSchema = z.number().int().min(1).max(90); | |
| export const saveFollowUpSettingsBody = z.object({ | |
| followUpAwaitingReplyDays: daysSchema, | |
| followUpNeedsReplyDays: daysSchema, | |
| followUpAutoDraftEnabled: z.boolean(), |
Finding type: Type Inconsistency
Heads up!
Your free trial ends in 2 days.
To keep getting your PRs reviewed by Baz, update your team's subscription
| export const scanFollowUpRemindersAction = actionClient | ||
| .metadata({ name: "scanFollowUpReminders" }) | ||
| .inputSchema(z.object({})) | ||
| .action(async ({ ctx: { emailAccountId, logger } }) => { | ||
| const emailAccount = await prisma.emailAccount.findUnique({ | ||
| where: { id: emailAccountId }, | ||
| select: { | ||
| id: true, | ||
| email: true, | ||
| followUpAwaitingReplyDays: true, | ||
| followUpNeedsReplyDays: true, | ||
| followUpAutoDraftEnabled: true, | ||
| account: { select: { provider: true } }, | ||
| }, | ||
| }); | ||
|
|
||
| if (!emailAccount) throw new SafeError("Email account not found"); | ||
|
|
||
| await processAccountFollowUps({ emailAccount, logger }); |
There was a problem hiding this comment.
scanFollowUpRemindersAction only selects id, email, follow-up thresholds, the auto-draft flag, and the provider before calling processAccountFollowUps, but that helper assumes an EmailAccountWithAI, including user + AI config, userId, timezone, about, etc. When followUpAutoDraftEnabled is true, the scan flow runs generateFollowUpDraft, which calls fetchMessagesAndGenerateDraft → aiCollectReplyContext → getModel(emailAccount.user, …) and getOrCreateReferralCode(emailAccount.userId). Because emailAccount.user and userId are missing in the Scan path, those calls receive undefined and immediately throw, so "Scan now" crashes whenever auto-draft is enabled. The manual scan needs to select the same fields as the cron job (or change its contract) before passing the account into processAccountFollowUps.
Prompt for AI Agents:
In apps/web/utils/actions/follow-up-reminders.ts around lines 46-64, the
scanFollowUpRemindersAction's prisma.emailAccount.findUnique only selects id, email,
follow-up settings and provider but processAccountFollowUps expects a full
EmailAccountWithAI (including user, userId, timezone, about and AI-related config).
Change the select to include the same fields the cron/regular flow uses (at minimum:
user (id and any fields used by getModel/getOrCreateReferralCode), userId, timezone,
about, and any AI configuration/referral fields), or select the full account relation
structure that processAccountFollowUps expects. Also keep the existing not-found guard
and consider adding an explicit check and a clear error if required user/AI fields are
still missing.
Finding type: Logical Bugs
Heads up!
Your free trial ends in 2 days.
To keep getting your PRs reviewed by Baz, update your team's subscription
There was a problem hiding this comment.
Commit ec885c1 addressed this comment by expanding the select statement in scanFollowUpRemindersAction to include all the missing fields required by processAccountFollowUps. The new code now selects userId, about, timezone, and the user relation with AI configuration fields (aiProvider, aiModel, aiApiKey), which prevents the crash when followUpAutoDraftEnabled is true and ensures getModel and getOrCreateReferralCode receive the necessary data instead of undefined.
There was a problem hiding this comment.
Actionable comments posted: 5
🤖 Fix all issues with AI agents
In @apps/web/__tests__/e2e/flows/full-reply-cycle.test.ts:
- Around line 290-295: The test is using a hardcoded subject string in the
waitForMessageInInbox call which is inconsistent with the earlier use of
initialEmail.fullSubject and can cause flaky matches; update the call to
waitForMessageInInbox (the invocation that assigns gmailReply) to use
initialEmail.fullSubject (or the same variable used at line 273) for
subjectContains so the test consistently matches the exact message created by
this run.
- Around line 313-318: The test uses a hardcoded subject string when calling
waitForMessageInInbox for outlookMsg2 which can cause mismatches; update that
call to use initialEmail.fullSubject (the same pattern used earlier) so
waitForMessageInInbox({ provider: outlook.emailProvider, subjectContains:
initialEmail.fullSubject, timeout: TIMEOUTS.EMAIL_DELIVERY }) reliably matches
the intended message.
In
@apps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsx:
- Around line 216-233: The label's htmlFor ("followUpAutoDraftEnabled") isn't
tied to an input; fix by giving the Toggle an id and wiring it through: update
the Toggle component API to accept an id prop (e.g., id: string) and pass that
id to the underlying input/Switch, then set the <label htmlFor> to the same id
("followUpAutoDraftEnabled"); keep the Toggle usage with
enabled={autoDraftValue} and onChange={(value) =>
setValue("followUpAutoDraftEnabled", value)} so the label properly associates
with the control for screen readers.
In @apps/web/env.ts:
- Line 192: Add the missing environment variable
NEXT_PUBLIC_FOLLOW_UP_REMINDERS_ENABLED to the .env.example alongside the other
feature flags, using the same commented pattern as the existing entries (e.g.,
"# NEXT_PUBLIC_FOLLOW_UP_REMINDERS_ENABLED=true") so it appears with
NEXT_PUBLIC_DIGEST_ENABLED, NEXT_PUBLIC_MEETING_BRIEFS_ENABLED, and
NEXT_PUBLIC_INTEGRATIONS_ENABLED.
In @apps/web/utils/actions/follow-up-reminders.ts:
- Around line 46-65: scanFollowUpRemindersAction fetches an incomplete
emailAccount and passes it to processAccountFollowUps, which expects the full
EmailAccountWithAI shape (including user AI settings) so auto-draft can work;
update the prisma.findUnique select in scanFollowUpRemindersAction to include
the user and all AI-related fields required by processAccountFollowUps (e.g.,
user.{id, aiModel, aiTemperature, aiMaxTokens, ...} or whatever fields comprise
EmailAccountWithAI) or replace the select with a call that returns the full
EmailAccountWithAI object before calling processAccountFollowUps.
🧹 Nitpick comments (5)
apps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsx (2)
45-69: Close the “Configure” dialog when reminders are disabled (prevents staleopen=truestate).If the user turns the feature off while the dialog is open,
openremainstrueand the dialog can pop back open when re-enabled.Proposed tweak
const handleToggle = useCallback( (enable: boolean) => { if (!data) return; + if (!enable) setOpen(false); + const optimisticData = { ...data, followUpRemindersEnabled: enable, }; mutate(optimisticData, false); executeToggle({ enabled: enable }); }, - [data, mutate, executeToggle], + [data, mutate, executeToggle], );
126-156: Consider client-side Zod validation (zodResolver) for days inputs.Right now, invalid values will likely only be surfaced after the server action runs. Adding
zodResolver(saveFollowUpSettingsBody)would give faster feedback and align with the repo’s form handling guidance.Also applies to: 187-214
apps/web/utils/follow-up/labels.test.ts (1)
1-51: Nice coverage for “label exists” vs “create label” cases.One small improvement: import the shared follow-up label constant (if exported) instead of repeating
"Follow-up"throughout, to reduce brittleness if the label name changes.apps/web/utils/follow-up/cleanup.ts (1)
40-44: Confirm provider draft pagination behavior (maxResults: 100).If an account can have >100 drafts, cleanup may miss stale ones. If
provider.getDraftssupports paging, consider looping until exhaustion (with a sane cap) or filtering server-side if available.apps/web/utils/actions/follow-up-reminders.validation.ts (1)
10-16: Add descriptive Zod messages for days validation.This makes server errors clearer and supports future client-side resolver usage.
Proposed tweak
-const daysSchema = z.number().min(0.001).max(90); +const daysSchema = z + .number({ message: "Must be a number of days" }) + .min(0.001, "Must be greater than 0") + .max(90, "Must be 90 days or less");
| // Wait for Gmail to receive | ||
| const gmailReply = await waitForMessageInInbox({ | ||
| provider: gmail.emailProvider, | ||
| subjectContains: initialEmail.fullSubject, | ||
| subjectContains: "Thread continuity test", | ||
| timeout: TIMEOUTS.EMAIL_DELIVERY, | ||
| }); |
There was a problem hiding this comment.
Inconsistent subject matching could cause flaky tests.
The test uses initialEmail.fullSubject at line 273 but switches to the hardcoded base subject "Thread continuity test" here. This inconsistency could lead to matching unintended messages from previous test runs or concurrent tests.
🔧 Suggested fix for consistency
- // Wait for Gmail to receive
const gmailReply = await waitForMessageInInbox({
provider: gmail.emailProvider,
- subjectContains: "Thread continuity test",
+ subjectContains: initialEmail.fullSubject,
timeout: TIMEOUTS.EMAIL_DELIVERY,
});🤖 Prompt for AI Agents
In @apps/web/__tests__/e2e/flows/full-reply-cycle.test.ts around lines 290 -
295, The test is using a hardcoded subject string in the waitForMessageInInbox
call which is inconsistent with the earlier use of initialEmail.fullSubject and
can cause flaky matches; update the call to waitForMessageInInbox (the
invocation that assigns gmailReply) to use initialEmail.fullSubject (or the same
variable used at line 273) for subjectContains so the test consistently matches
the exact message created by this run.
| // Wait for Outlook to receive | ||
| const outlookMsg2 = await waitForMessageInInbox({ | ||
| provider: outlook.emailProvider, | ||
| subjectContains: initialEmail.fullSubject, | ||
| subjectContains: "Thread continuity test", | ||
| timeout: TIMEOUTS.EMAIL_DELIVERY, | ||
| }); |
There was a problem hiding this comment.
Same inconsistency - use fullSubject for reliable matching.
Similar to the issue at lines 290-295, this should use initialEmail.fullSubject instead of the hardcoded base subject to ensure the test matches the correct message reliably.
🔧 Suggested fix for consistency
- // Wait for Outlook to receive
const outlookMsg2 = await waitForMessageInInbox({
provider: outlook.emailProvider,
- subjectContains: "Thread continuity test",
+ subjectContains: initialEmail.fullSubject,
timeout: TIMEOUTS.EMAIL_DELIVERY,
});🤖 Prompt for AI Agents
In @apps/web/__tests__/e2e/flows/full-reply-cycle.test.ts around lines 313 -
318, The test uses a hardcoded subject string when calling waitForMessageInInbox
for outlookMsg2 which can cause mismatches; update that call to use
initialEmail.fullSubject (the same pattern used earlier) so
waitForMessageInInbox({ provider: outlook.emailProvider, subjectContains:
initialEmail.fullSubject, timeout: TIMEOUTS.EMAIL_DELIVERY }) reliably matches
the intended message.
| <div className="flex items-center justify-between"> | ||
| <div> | ||
| <label | ||
| htmlFor="followUpAutoDraftEnabled" | ||
| className="block text-sm font-medium text-foreground" | ||
| > | ||
| Auto-generate drafts | ||
| </label> | ||
| <p className="text-muted-foreground text-sm"> | ||
| Draft a nudge when you haven't heard back. | ||
| </p> | ||
| </div> | ||
| <Toggle | ||
| name="followUpAutoDraftEnabled" | ||
| enabled={autoDraftValue} | ||
| onChange={(value) => setValue("followUpAutoDraftEnabled", value)} | ||
| /> | ||
| </div> |
There was a problem hiding this comment.
Fix label → control association for “Auto-generate drafts”.
<label htmlFor="followUpAutoDraftEnabled"> doesn’t appear to target an actual input id, so screen readers won’t have a proper association. As written, the Toggle component also doesn’t receive an id to wire up.
Options:
- Use
Toggle’s built-inlabel/explainTextprops instead of a standalone<label>, or - Extend
Toggleto accept anidand pass it to the underlyingSwitch, then sethtmlForto that id.
(Based on coding guidelines: “Make sure label elements have text content and are associated with an input”.)
🤖 Prompt for AI Agents
In
@apps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsx
around lines 216 - 233, The label's htmlFor ("followUpAutoDraftEnabled") isn't
tied to an input; fix by giving the Toggle an id and wiring it through: update
the Toggle component API to accept an id prop (e.g., id: string) and pass that
id to the underlying input/Switch, then set the <label htmlFor> to the same id
("followUpAutoDraftEnabled"); keep the Toggle usage with
enabled={autoDraftValue} and onChange={(value) =>
setValue("followUpAutoDraftEnabled", value)} so the label properly associates
with the control for screen readers.
…d streamline logic for enabling reminders
apps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsx
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
apps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsx (1)
132-144: Consider adding Zod resolver for client-side validation.The form uses
useFormwithoutzodResolver, relying on HTML attributes (min,max,step) and server-side validation. While this works, addingzodResolverwithsaveFollowUpSettingsFormBodywould provide immediate client-side feedback for invalid inputs.♻️ Optional: Add zodResolver for client-side validation
+import { zodResolver } from "@hookform/resolvers/zod"; +import { saveFollowUpSettingsFormBody } from "@/utils/actions/follow-up-reminders.validation"; const { register, handleSubmit, watch, setValue, formState: { errors }, } = useForm<SaveFollowUpSettingsFormInput>({ + resolver: zodResolver(saveFollowUpSettingsFormBody), defaultValues: { followUpAwaitingReplyDays: followUpAwaitingReplyDays?.toString() ?? "", followUpNeedsReplyDays: followUpNeedsReplyDays?.toString() ?? "", followUpAutoDraftEnabled, }, });
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
apps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsxapps/web/app/api/follow-up-reminders/process.tsapps/web/app/api/user/email-account/route.tsapps/web/prisma/migrations/20260111000000_add_follow_up_reminders/migration.sqlapps/web/prisma/schema.prismaapps/web/utils/actions/follow-up-reminders.tsapps/web/utils/actions/follow-up-reminders.validation.ts
🚧 Files skipped from review as they are similar to previous changes (1)
- apps/web/app/api/user/email-account/route.ts
🧰 Additional context used
📓 Path-based instructions (29)
**/prisma/schema.prisma
📄 CodeRabbit inference engine (.cursor/rules/prisma.mdc)
Use PostgreSQL as the database system with Prisma
Files:
apps/web/prisma/schema.prisma
!(pages/_document).{jsx,tsx}
📄 CodeRabbit inference engine (.cursor/rules/ultracite.mdc)
Don't use the next/head module in pages/_document.js on Next.js projects
Files:
apps/web/prisma/schema.prismaapps/web/utils/actions/follow-up-reminders.tsapps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsxapps/web/app/api/follow-up-reminders/process.tsapps/web/prisma/migrations/20260111000000_add_follow_up_reminders/migration.sqlapps/web/utils/actions/follow-up-reminders.validation.ts
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/data-fetching.mdc)
**/*.{ts,tsx}: For API GET requests to server, use theswrpackage
Useresult?.serverErrorwithtoastErrorfrom@/components/Toastfor error handling in async operations
**/*.{ts,tsx}: Use wrapper functions for Gmail message operations (get, list, batch, etc.) from @/utils/gmail/message.ts instead of direct API calls
Use wrapper functions for Gmail thread operations from @/utils/gmail/thread.ts instead of direct API calls
Use wrapper functions for Gmail label operations from @/utils/gmail/label.ts instead of direct API calls
**/*.{ts,tsx}: For early access feature flags, create hooks using the naming conventionuse[FeatureName]Enabledthat return a boolean fromuseFeatureFlagEnabled("flag-key")
For A/B test variant flags, create hooks using the naming conventionuse[FeatureName]Variantthat define variant types, useuseFeatureFlagVariantKey()with type casting, and provide a default "control" fallback
Use kebab-case for PostHog feature flag keys (e.g.,inbox-cleaner,pricing-options-2)
Always define types for A/B test variant flags (e.g.,type PricingVariant = "control" | "variant-a" | "variant-b") and provide type safety through type casting
**/*.{ts,tsx}: Don't use primitive type aliases or misleading types
Don't use empty type parameters in type aliases and interfaces
Don't use this and super in static contexts
Don't use any or unknown as type constraints
Don't use the TypeScript directive @ts-ignore
Don't use TypeScript enums
Don't export imported variables
Don't add type annotations to variables, parameters, and class properties that are initialized with literal expressions
Don't use TypeScript namespaces
Don't use non-null assertions with the!postfix operator
Don't use parameter properties in class constructors
Don't use user-defined types
Useas constinstead of literal types and type annotations
Use eitherT[]orArray<T>consistently
Initialize each enum member value explicitly
Useexport typefor types
Use `impo...
Files:
apps/web/utils/actions/follow-up-reminders.tsapps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsxapps/web/app/api/follow-up-reminders/process.tsapps/web/utils/actions/follow-up-reminders.validation.ts
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.cursor/rules/prisma-enum-imports.mdc)
Always import Prisma enums from
@/generated/prisma/enumsinstead of@/generated/prisma/clientto avoid Next.js bundling errors in client componentsImport Prisma using the project's centralized utility:
import prisma from '@/utils/prisma'
Files:
apps/web/utils/actions/follow-up-reminders.tsapps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsxapps/web/app/api/follow-up-reminders/process.tsapps/web/utils/actions/follow-up-reminders.validation.ts
apps/web/utils/actions/**/*.ts
📄 CodeRabbit inference engine (.cursor/rules/project-structure.mdc)
apps/web/utils/actions/**/*.ts: Server actions must be located inapps/web/utils/actionsfolder
Server action files must start withuse serverdirective
Files:
apps/web/utils/actions/follow-up-reminders.tsapps/web/utils/actions/follow-up-reminders.validation.ts
apps/web/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/project-structure.mdc)
Import specific lodash functions rather than entire lodash library to minimize bundle size (e.g.,
import groupBy from 'lodash/groupBy')
apps/web/**/*.{ts,tsx}: Use TypeScript with strict null checks
Do not export types/interfaces that are only used within the same file. Export later if needed
Infer types from Zod schemas usingz.infer<typeof schema>instead of duplicating as separate interfaces
Files:
apps/web/utils/actions/follow-up-reminders.tsapps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsxapps/web/app/api/follow-up-reminders/process.tsapps/web/utils/actions/follow-up-reminders.validation.ts
**/*.ts
📄 CodeRabbit inference engine (.cursor/rules/security.mdc)
**/*.ts: ALL database queries MUST be scoped to the authenticated user/account by including user/account filtering in WHERE clauses to prevent unauthorized data access
Always validate that resources belong to the authenticated user before performing operations, using ownership checks in WHERE clauses or relationships
Always validate all input parameters for type, format, and length before using them in database queries
Use SafeError for error responses to prevent information disclosure. Generic error messages should not reveal internal IDs, logic, or resource ownership details
Only return necessary fields in API responses using Prisma'sselectoption. Never expose sensitive data such as password hashes, private keys, or system flags
Prevent Insecure Direct Object References (IDOR) by validating resource ownership before operations. AllfindUnique/findFirstcalls MUST include ownership filters
Prevent mass assignment vulnerabilities by explicitly whitelisting allowed fields in update operations instead of accepting all user-provided data
Prevent privilege escalation by never allowing users to modify system fields, ownership fields, or admin-only attributes through user input
AllfindManyqueries MUST be scoped to the user's data by including appropriate WHERE filters to prevent returning data from other users
Use Prisma relationships for access control by leveraging nested where clauses (e.g.,emailAccount: { id: emailAccountId }) to validate ownership
Files:
apps/web/utils/actions/follow-up-reminders.tsapps/web/app/api/follow-up-reminders/process.tsapps/web/utils/actions/follow-up-reminders.validation.ts
apps/web/utils/actions/*.ts
📄 CodeRabbit inference engine (.cursor/rules/server-actions.mdc)
apps/web/utils/actions/*.ts: Create corresponding server action implementation files using the naming conventionapps/web/utils/actions/NAME.tswith 'use server' directive
Use 'use server' directive at the top of server action implementation files
Implement all server actions using thenext-safe-actionlibrary with actionClient, actionClientUser, or adminActionClient for type safety and validation
UseactionClientUserwhen only authenticated user context (userId) is needed
UseactionClientwhen both authenticated user context and a specific emailAccountId are needed, with emailAccountId bound when calling from the client
UseadminActionClientfor actions restricted to admin users
Add metadata with a meaningful action name using.metadata({ name: "actionName" })for Sentry instrumentation and monitoring
Use.schema()method with Zod validation schemas from corresponding.validation.tsfiles in next-safe-action configuration
Access context (userId, emailAccountId, etc.) via thectxobject parameter in the.action()handler
UserevalidatePathorrevalidateTagfrom 'next/cache' within server action handlers when mutations modify data displayed elsewhere
apps/web/utils/actions/*.ts: Usenext-safe-actionwith proper Zod validation for server actions
Server actions should useactionClient.metadata({ name: 'actionName' }).schema(schema).action(...)pattern
CallrevalidatePathin server actions after successful mutations
UserevalidatePathin server actions for cache invalidation
Files:
apps/web/utils/actions/follow-up-reminders.tsapps/web/utils/actions/follow-up-reminders.validation.ts
**/*.{tsx,ts}
📄 CodeRabbit inference engine (.cursor/rules/ui-components.mdc)
**/*.{tsx,ts}: Use Shadcn UI and Tailwind for components and styling
Usenext/imagepackage for images
For API GET requests to server, use theswrpackage with hooks likeuseSWRto fetch data
For text inputs, use theInputcomponent withregisterPropsfor form integration and error handling
Files:
apps/web/utils/actions/follow-up-reminders.tsapps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsxapps/web/app/api/follow-up-reminders/process.tsapps/web/utils/actions/follow-up-reminders.validation.ts
**/*.{tsx,ts,css}
📄 CodeRabbit inference engine (.cursor/rules/ui-components.mdc)
Implement responsive design with Tailwind CSS using a mobile-first approach
Files:
apps/web/utils/actions/follow-up-reminders.tsapps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsxapps/web/app/api/follow-up-reminders/process.tsapps/web/utils/actions/follow-up-reminders.validation.ts
**/*.{js,jsx,ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/ultracite.mdc)
**/*.{js,jsx,ts,tsx}: Don't useaccessKeyattribute on any HTML element
Don't setaria-hidden="true"on focusable elements
Don't add ARIA roles, states, and properties to elements that don't support them
Don't use distracting elements like<marquee>or<blink>
Only use thescopeprop on<th>elements
Don't assign non-interactive ARIA roles to interactive HTML elements
Make sure label elements have text content and are associated with an input
Don't assign interactive ARIA roles to non-interactive HTML elements
Don't assigntabIndexto non-interactive HTML elements
Don't use positive integers fortabIndexproperty
Don't include "image", "picture", or "photo" in img alt prop
Don't use explicit role property that's the same as the implicit/default role
Make static elements with click handlers use a valid role attribute
Always include atitleelement for SVG elements
Give all elements requiring alt text meaningful information for screen readers
Make sure anchors have content that's accessible to screen readers
AssigntabIndexto non-interactive HTML elements witharia-activedescendant
Include all required ARIA attributes for elements with ARIA roles
Make sure ARIA properties are valid for the element's supported roles
Always include atypeattribute for button elements
Make elements with interactive roles and handlers focusable
Give heading elements content that's accessible to screen readers (not hidden witharia-hidden)
Always include alangattribute on the html element
Always include atitleattribute for iframe elements
AccompanyonClickwith at least one of:onKeyUp,onKeyDown, oronKeyPress
AccompanyonMouseOver/onMouseOutwithonFocus/onBlur
Include caption tracks for audio and video elements
Use semantic elements instead of role attributes in JSX
Make sure all anchors are valid and navigable
Ensure all ARIA properties (aria-*) are valid
Use valid, non-abstract ARIA roles for elements with ARIA roles
Use valid AR...
Files:
apps/web/utils/actions/follow-up-reminders.tsapps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsxapps/web/app/api/follow-up-reminders/process.tsapps/web/utils/actions/follow-up-reminders.validation.ts
**/*.{js,ts,jsx,tsx}
📄 CodeRabbit inference engine (.cursor/rules/utilities.mdc)
**/*.{js,ts,jsx,tsx}: Use lodash utilities for common operations (arrays, objects, strings)
Import specific lodash functions to minimize bundle size (e.g.,import groupBy from 'lodash/groupBy')
**/*.{js,ts,jsx,tsx}: Add helper functions to the bottom of files, not the top!
All imports go at the top of files, no mid-file dynamic imports.
Files:
apps/web/utils/actions/follow-up-reminders.tsapps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsxapps/web/app/api/follow-up-reminders/process.tsapps/web/utils/actions/follow-up-reminders.validation.ts
**/{utils,helpers,lib}/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/logging.mdc)
Logger should be passed as a parameter to helper functions instead of creating their own logger instances
Files:
apps/web/utils/actions/follow-up-reminders.tsapps/web/utils/actions/follow-up-reminders.validation.ts
apps/web/utils/actions/!(*.validation).ts
📄 CodeRabbit inference engine (.cursor/rules/fullstack-workflow.mdc)
apps/web/utils/actions/!(*.validation).ts: Usenext-safe-actionfor all server actions withactionClient,.metadata(),.inputSchema(), and.action()chain pattern
Add'use server'directive at the top of all server action files
Files:
apps/web/utils/actions/follow-up-reminders.ts
apps/web/**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (apps/web/CLAUDE.md)
apps/web/**/*.{ts,tsx,js,jsx}: Use@/path aliases for imports from project root
Use proper error handling with try/catch blocks
Prefer self-documenting code over comments; use descriptive variable and function names instead of explaining intent with comments. Never add comments that just describe what the code does. Only add comments for 'why' not 'what'
Add helper functions to the bottom of files, not the top
All imports go at the top of files, no mid-file dynamic imports
UsegetActionErrorMessage(error.error)from@/utils/errorto extract user-friendly error messages
Files:
apps/web/utils/actions/follow-up-reminders.tsapps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsxapps/web/app/api/follow-up-reminders/process.tsapps/web/utils/actions/follow-up-reminders.validation.ts
apps/web/**/*.{ts,tsx,css}
📄 CodeRabbit inference engine (apps/web/CLAUDE.md)
Follow tailwindcss patterns with prettier-plugin-tailwindcss
Files:
apps/web/utils/actions/follow-up-reminders.tsapps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsxapps/web/app/api/follow-up-reminders/process.tsapps/web/utils/actions/follow-up-reminders.validation.ts
apps/web/**/*.{ts,tsx,js,jsx,json}
📄 CodeRabbit inference engine (apps/web/CLAUDE.md)
Client-side environment variables must be prefixed with
NEXT_PUBLIC_
Files:
apps/web/utils/actions/follow-up-reminders.tsapps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsxapps/web/app/api/follow-up-reminders/process.tsapps/web/utils/actions/follow-up-reminders.validation.ts
**/*.{js,ts,jsx,tsx,py,java,cs,rb,go,php,rs,kt,swift,m}
📄 CodeRabbit inference engine (.cursor/rules/notes.mdc)
Prefer self-documenting code over comments; use descriptive variable and function names instead of explaining intent with comments. Never add comments that just describe what the code does - code should explain itself. Only add comments for 'why' not 'what'.
Files:
apps/web/utils/actions/follow-up-reminders.tsapps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsxapps/web/app/api/follow-up-reminders/process.tsapps/web/utils/actions/follow-up-reminders.validation.ts
apps/web/app/(app)/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/page-structure.mdc)
apps/web/app/(app)/**/*.{ts,tsx}: Components for the page are either put inpage.tsx, or in theapps/web/app/(app)/PAGE_NAMEfolder
If we're in a deeply nested component we will useswrto fetch via API
If you need to useonClickin a component, that component is a client component and file must start withuse client
Files:
apps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsx
**/*.tsx
📄 CodeRabbit inference engine (.cursor/rules/ui-components.mdc)
**/*.tsx: Use theLoadingContentcomponent to handle loading states instead of manual loading state management
For text areas, use theInputcomponent withtype='text',autosizeTextareaprop set to true, andregisterPropsfor form integration
Files:
apps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsx
**/*.{jsx,tsx}
📄 CodeRabbit inference engine (.cursor/rules/ultracite.mdc)
**/*.{jsx,tsx}: Don't use unnecessary fragments
Don't pass children as props
Don't use the return value of React.render
Make sure all dependencies are correctly specified in React hooks
Make sure all React hooks are called from the top level of component functions
Don't forget key props in iterators and collection literals
Don't define React components inside other components
Don't use event handlers on non-interactive elements
Don't assign to React component props
Don't use bothchildrenanddangerouslySetInnerHTMLprops on the same element
Don't use dangerous JSX props
Don't use Array index in keys
Don't insert comments as text nodes
Don't assign JSX properties multiple times
Don't add extra closing tags for components without children
Use<>...</>instead of<Fragment>...</Fragment>
Watch out for possible "wrong" semicolons inside JSX elements
Make sure void (self-closing) elements don't have children
Don't usetarget="_blank"withoutrel="noopener"
Don't use<img>elements in Next.js projects
Don't use<head>elements in Next.js projects
Files:
apps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsx
apps/web/**/*.{tsx,jsx}
📄 CodeRabbit inference engine (apps/web/CLAUDE.md)
apps/web/**/*.{tsx,jsx}: Prefer functional components with hooks
Use shadcn/ui components when available
Follow consistent naming conventions (PascalCase for components)
Use LoadingContent component for async data with loading and error states
Use React Hook Form with Zod validation for form handling
UseuseActionhook fromnext-safe-action/hookswithonSuccessandonErrorcallbacks for form submission
Use LoadingContent component to handle loading and error states consistently
Callmutate()after successful mutations to refresh SWR data
Files:
apps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsx
apps/web/**/*.{tsx,jsx,css}
📄 CodeRabbit inference engine (apps/web/CLAUDE.md)
Ensure responsive design with mobile-first approach
Files:
apps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsx
apps/web/app/api/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/security-audit.mdc)
apps/web/app/api/**/*.{ts,tsx}: API routes must usewithAuth,withEmailAccount, orwithErrormiddleware for authentication
All database queries must include user scoping withemailAccountIdoruserIdfiltering in WHERE clauses
Request parameters must be validated before use; avoid direct parameter usage without type checking
Use generic error messages instead of revealing internal details; throwSafeErrorinstead of exposing user IDs, resource IDs, or system information
API routes should only return necessary fields usingselectin database queries to prevent unintended information disclosure
Cron endpoints must usehasCronSecretorhasPostCronSecretto validate cron requests and prevent unauthorized access
Request bodies should use Zod schemas for validation to ensure type safety and prevent injection attacks
Files:
apps/web/app/api/follow-up-reminders/process.ts
**/app/api/**/*.ts
📄 CodeRabbit inference engine (.cursor/rules/security.mdc)
**/app/api/**/*.ts: ALL API routes that handle user data MUST use appropriate middleware: usewithEmailAccountfor email-scoped operations, usewithAuthfor user-scoped operations, or usewithErrorwith proper validation for public/custom auth endpoints
UsewithEmailAccountmiddleware for operations scoped to a specific email account, including reading/writing emails, rules, schedules, or any operation usingemailAccountId
UsewithAuthmiddleware for user-level operations such as user settings, API keys, and referrals that use onlyuserId
UsewithErrormiddleware only for public endpoints, custom authentication logic, or cron endpoints. For cron endpoints, MUST usehasCronSecret()orhasPostCronSecret()validation
Cron endpoints without proper authentication can be triggered by anyone. CRITICAL: All cron endpoints MUST validate cron secret usinghasCronSecret(request)orhasPostCronSecret(request)and capture unauthorized attempts withcaptureException()
Always validate request bodies using Zod schemas to ensure type safety and prevent invalid data from reaching database operations
Maintain consistent error response format across all API routes to avoid information disclosure while providing meaningful error feedback
Files:
apps/web/app/api/follow-up-reminders/process.ts
apps/web/app/api/**/*.ts
📄 CodeRabbit inference engine (.cursor/rules/fullstack-workflow.mdc)
apps/web/app/api/**/*.ts: Do NOT use POST API routes for mutations - use server actions instead
UsewithAuthmiddleware for user-level API operations andwithEmailAccountmiddleware for email-account-level operations
Files:
apps/web/app/api/follow-up-reminders/process.ts
**/*.validation.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/form-handling.mdc)
**/*.validation.{ts,tsx}: Define validation schemas using Zod
Use descriptive error messages in validation schemas
Files:
apps/web/utils/actions/follow-up-reminders.validation.ts
apps/web/utils/actions/*.validation.ts
📄 CodeRabbit inference engine (.cursor/rules/server-actions.mdc)
apps/web/utils/actions/*.validation.ts: Create separate validation files for server actions using the naming conventionapps/web/utils/actions/NAME.validation.tscontaining Zod schemas and inferred types
Define input validation schemas using Zod in.validation.tsfiles and export both the schema and its inferred TypeScript typeValidation schemas should be in separate files (e.g.,
utils/actions/example.validation.ts)
Files:
apps/web/utils/actions/follow-up-reminders.validation.ts
apps/web/utils/actions/**/*.validation.ts
📄 CodeRabbit inference engine (.cursor/rules/fullstack-workflow.mdc)
Create Zod validation schemas at
apps/web/utils/actions/{feature}.validation.tsfor all server action input validation
Files:
apps/web/utils/actions/follow-up-reminders.validation.ts
🧠 Learnings (56)
📚 Learning: 2025-11-25T14:39:49.448Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/server-actions.mdc:0-0
Timestamp: 2025-11-25T14:39:49.448Z
Learning: Applies to apps/web/utils/actions/*.ts : Create corresponding server action implementation files using the naming convention `apps/web/utils/actions/NAME.ts` with 'use server' directive
Applied to files:
apps/web/utils/actions/follow-up-reminders.ts
📚 Learning: 2026-01-09T21:51:15.182Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: apps/web/CLAUDE.md:0-0
Timestamp: 2026-01-09T21:51:15.182Z
Learning: Applies to apps/web/utils/actions/*.ts : Server actions should use `actionClient.metadata({ name: 'actionName' }).schema(schema).action(...)` pattern
Applied to files:
apps/web/utils/actions/follow-up-reminders.ts
📚 Learning: 2025-11-25T14:39:49.448Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/server-actions.mdc:0-0
Timestamp: 2025-11-25T14:39:49.448Z
Learning: Applies to apps/web/utils/actions/*.ts : Implement all server actions using the `next-safe-action` library with actionClient, actionClientUser, or adminActionClient for type safety and validation
Applied to files:
apps/web/utils/actions/follow-up-reminders.ts
📚 Learning: 2025-11-25T14:39:49.448Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/server-actions.mdc:0-0
Timestamp: 2025-11-25T14:39:49.448Z
Learning: Applies to apps/web/utils/actions/*.validation.ts : Create separate validation files for server actions using the naming convention `apps/web/utils/actions/NAME.validation.ts` containing Zod schemas and inferred types
Applied to files:
apps/web/utils/actions/follow-up-reminders.tsapps/web/utils/actions/follow-up-reminders.validation.ts
📚 Learning: 2026-01-08T15:09:06.736Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/fullstack-workflow.mdc:0-0
Timestamp: 2026-01-08T15:09:06.736Z
Learning: Applies to apps/web/utils/actions/!(*.validation).ts : Use `next-safe-action` for all server actions with `actionClient`, `.metadata()`, `.inputSchema()`, and `.action()` chain pattern
Applied to files:
apps/web/utils/actions/follow-up-reminders.ts
📚 Learning: 2026-01-08T15:09:06.736Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/fullstack-workflow.mdc:0-0
Timestamp: 2026-01-08T15:09:06.736Z
Learning: Applies to apps/web/utils/actions/!(*.validation).ts : Add `'use server'` directive at the top of all server action files
Applied to files:
apps/web/utils/actions/follow-up-reminders.ts
📚 Learning: 2025-11-25T14:39:27.909Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-11-25T14:39:27.909Z
Learning: Applies to **/app/api/**/*.ts : Use `withEmailAccount` middleware for operations scoped to a specific email account, including reading/writing emails, rules, schedules, or any operation using `emailAccountId`
Applied to files:
apps/web/utils/actions/follow-up-reminders.tsapps/web/app/api/follow-up-reminders/process.ts
📚 Learning: 2025-11-25T14:38:07.606Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/llm.mdc:0-0
Timestamp: 2025-11-25T14:38:07.606Z
Learning: Applies to apps/web/utils/ai/**/*.ts : LLM feature functions must import from `zod` for schema validation, use `createScopedLogger` from `@/utils/logger`, `chatCompletionObject` and `createGenerateObject` from `@/utils/llms`, and import `EmailAccountWithAI` type from `@/utils/llms/types`
Applied to files:
apps/web/utils/actions/follow-up-reminders.tsapps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsxapps/web/app/api/follow-up-reminders/process.tsapps/web/utils/actions/follow-up-reminders.validation.ts
📚 Learning: 2025-11-25T14:38:56.992Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/project-structure.mdc:0-0
Timestamp: 2025-11-25T14:38:56.992Z
Learning: Applies to apps/web/utils/actions/**/*.ts : Server actions must be located in `apps/web/utils/actions` folder
Applied to files:
apps/web/utils/actions/follow-up-reminders.ts
📚 Learning: 2025-11-25T14:39:49.448Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/server-actions.mdc:0-0
Timestamp: 2025-11-25T14:39:49.448Z
Learning: Applies to apps/web/utils/actions/*.ts : Use `actionClient` when both authenticated user context and a specific emailAccountId are needed, with emailAccountId bound when calling from the client
Applied to files:
apps/web/utils/actions/follow-up-reminders.ts
📚 Learning: 2026-01-09T21:51:15.182Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: apps/web/CLAUDE.md:0-0
Timestamp: 2026-01-09T21:51:15.182Z
Learning: Applies to apps/web/utils/actions/*.ts : Call `revalidatePath` in server actions after successful mutations
Applied to files:
apps/web/utils/actions/follow-up-reminders.ts
📚 Learning: 2025-11-25T14:39:49.448Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/server-actions.mdc:0-0
Timestamp: 2025-11-25T14:39:49.448Z
Learning: Applies to apps/web/utils/actions/*.ts : Use `revalidatePath` or `revalidateTag` from 'next/cache' within server action handlers when mutations modify data displayed elsewhere
Applied to files:
apps/web/utils/actions/follow-up-reminders.ts
📚 Learning: 2026-01-09T21:51:15.182Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: apps/web/CLAUDE.md:0-0
Timestamp: 2026-01-09T21:51:15.182Z
Learning: Applies to apps/web/utils/actions/*.ts : Use `revalidatePath` in server actions for cache invalidation
Applied to files:
apps/web/utils/actions/follow-up-reminders.ts
📚 Learning: 2025-12-17T02:38:41.499Z
Learnt from: elie222
Repo: elie222/inbox-zero PR: 1103
File: apps/web/utils/actions/rule.ts:447-457
Timestamp: 2025-12-17T02:38:41.499Z
Learning: In apps/web/utils/actions/rule.ts, revalidatePath is not needed for toggleAllRulesAction because rules data is fetched client-side using SWR, not server-side. Server-side cache revalidation is only needed when using Next.js server components or server-side data fetching.
Applied to files:
apps/web/utils/actions/follow-up-reminders.ts
📚 Learning: 2026-01-09T21:51:15.182Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: apps/web/CLAUDE.md:0-0
Timestamp: 2026-01-09T21:51:15.182Z
Learning: Applies to apps/web/utils/actions/*.ts : Use `next-safe-action` with proper Zod validation for server actions
Applied to files:
apps/web/utils/actions/follow-up-reminders.ts
📚 Learning: 2025-11-25T14:39:08.150Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-11-25T14:39:08.150Z
Learning: Applies to apps/web/app/api/**/*.{ts,tsx} : All database queries must include user scoping with `emailAccountId` or `userId` filtering in WHERE clauses
Applied to files:
apps/web/utils/actions/follow-up-reminders.ts
📚 Learning: 2025-07-08T13:14:07.449Z
Learnt from: elie222
Repo: elie222/inbox-zero PR: 537
File: apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx:30-34
Timestamp: 2025-07-08T13:14:07.449Z
Learning: The clean onboarding page in apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx is intentionally Gmail-specific and should show an error for non-Google email accounts rather than attempting to support multiple providers.
Applied to files:
apps/web/utils/actions/follow-up-reminders.ts
📚 Learning: 2025-11-25T14:38:07.606Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/llm.mdc:0-0
Timestamp: 2025-11-25T14:38:07.606Z
Learning: Applies to apps/web/utils/ai/**/*.ts : LLM feature functions must follow a standard structure: accept options with `inputData` and `emailAccount` parameters, implement input validation with early returns, define separate system and user prompts, create a Zod schema for response validation, and use `createGenerateObject` to execute the LLM call
Applied to files:
apps/web/utils/actions/follow-up-reminders.tsapps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsxapps/web/app/api/follow-up-reminders/process.ts
📚 Learning: 2026-01-05T13:44:57.575Z
Learnt from: elie222
Repo: elie222/inbox-zero PR: 1199
File: apps/web/utils/meeting-briefs/send-briefing.ts:0-0
Timestamp: 2026-01-05T13:44:57.575Z
Learning: In apps/web/utils/meeting-briefs/, the Zod schema in generate-briefing.ts intentionally only includes `{guests: GuestBriefing[]}` because the AI only generates guest briefings. The `internalTeamMembers` field comes from domain-based filtering in gather-context.ts (not AI-researched) and is merged into the BriefingContent in send-briefing.ts before sending the email. This separation keeps the Zod schema focused on what the AI actually generates.
<!-- [add_learning]
In the meeting briefing feature (apps/web/utils/meeting-briefs/), there's an intentional type separation: the Zod schema BriefingContent type from generate-briefing.ts differs from the email package BriefingContent type in packages/resend/emails/meeting-briefing.tsx. The AI-generated content uses a narrower type while the email content includes additional domain-filtered data merged in send-briefing.ts.
Applied to files:
apps/web/utils/actions/follow-up-reminders.ts
📚 Learning: 2025-11-25T14:38:07.606Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/llm.mdc:0-0
Timestamp: 2025-11-25T14:38:07.606Z
Learning: Applies to apps/web/utils/ai/**/*.ts : Implement early returns for invalid LLM inputs, use proper error types and logging, implement fallbacks for AI failures, and add retry logic for transient failures using `withRetry`
Applied to files:
apps/web/utils/actions/follow-up-reminders.tsapps/web/app/api/follow-up-reminders/process.ts
📚 Learning: 2025-11-25T14:39:23.326Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-11-25T14:39:23.326Z
Learning: Applies to app/api/**/*.ts : Use `withEmailAccount` middleware for operations scoped to a specific email account (reading/writing emails, rules, schedules, etc.) - provides `emailAccountId`, `userId`, and `email` in `request.auth`
Applied to files:
apps/web/utils/actions/follow-up-reminders.ts
📚 Learning: 2026-01-08T15:09:06.736Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/fullstack-workflow.mdc:0-0
Timestamp: 2026-01-08T15:09:06.736Z
Learning: Applies to apps/web/utils/actions/**/*.validation.ts : Create Zod validation schemas at `apps/web/utils/actions/{feature}.validation.ts` for all server action input validation
Applied to files:
apps/web/utils/actions/follow-up-reminders.tsapps/web/utils/actions/follow-up-reminders.validation.ts
📚 Learning: 2025-11-25T14:39:49.448Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/server-actions.mdc:0-0
Timestamp: 2025-11-25T14:39:49.448Z
Learning: Applies to apps/web/utils/actions/*.ts : Use `.schema()` method with Zod validation schemas from corresponding `.validation.ts` files in next-safe-action configuration
Applied to files:
apps/web/utils/actions/follow-up-reminders.tsapps/web/utils/actions/follow-up-reminders.validation.ts
📚 Learning: 2026-01-07T21:07:16.126Z
Learnt from: elie222
Repo: elie222/inbox-zero PR: 1230
File: apps/web/app/(app)/[emailAccountId]/drive/page.tsx:47-70
Timestamp: 2026-01-07T21:07:16.126Z
Learning: Direct server action calls with manual error handling (checking result?.serverError) are a valid pattern in this codebase. The useAction hook pattern is not required; developers can call server actions directly and handle errors manually, especially when using try/finally for cleanup operations like resetting loading states.
Applied to files:
apps/web/utils/actions/follow-up-reminders.ts
📚 Learning: 2026-01-08T15:09:06.736Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/fullstack-workflow.mdc:0-0
Timestamp: 2026-01-08T15:09:06.736Z
Learning: Applies to apps/web/components/**/*.tsx : Use React Hook Form with `zodResolver` for form validation, combining it with `useAction` hook from `next-safe-action/hooks` for server action execution
Applied to files:
apps/web/utils/actions/follow-up-reminders.tsapps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsx
📚 Learning: 2025-11-25T14:38:32.328Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/posthog-feature-flags.mdc:0-0
Timestamp: 2025-11-25T14:38:32.328Z
Learning: Applies to **/*.{ts,tsx} : For A/B test variant flags, create hooks using the naming convention `use[FeatureName]Variant` that define variant types, use `useFeatureFlagVariantKey()` with type casting, and provide a default "control" fallback
Applied to files:
apps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsx
📚 Learning: 2025-11-25T14:36:51.389Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/form-handling.mdc:0-0
Timestamp: 2025-11-25T14:36:51.389Z
Learning: Applies to **/*Form.{ts,tsx} : Validate form inputs before submission using React Hook Form and Zod resolver
Applied to files:
apps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsx
📚 Learning: 2025-11-25T14:38:07.606Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/llm.mdc:0-0
Timestamp: 2025-11-25T14:38:07.606Z
Learning: Applies to apps/web/utils/ai/**/*.ts : Always define a Zod schema for LLM response validation and make schemas as specific as possible to guide the LLM output
Applied to files:
apps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsxapps/web/utils/actions/follow-up-reminders.validation.ts
📚 Learning: 2026-01-09T21:51:15.182Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: apps/web/CLAUDE.md:0-0
Timestamp: 2026-01-09T21:51:15.182Z
Learning: Applies to apps/web/**/*.{tsx,jsx} : Use React Hook Form with Zod validation for form handling
Applied to files:
apps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsx
📚 Learning: 2025-11-25T14:36:53.147Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/form-handling.mdc:0-0
Timestamp: 2025-11-25T14:36:53.147Z
Learning: Applies to **/*Form.{ts,tsx} : Use React Hook Form with Zod for validation in form components
Applied to files:
apps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsxapps/web/utils/actions/follow-up-reminders.validation.ts
📚 Learning: 2025-11-25T14:36:51.389Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/form-handling.mdc:0-0
Timestamp: 2025-11-25T14:36:51.389Z
Learning: Applies to **/*Form.{ts,tsx} : Use React Hook Form with Zod for form validation
Applied to files:
apps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsx
📚 Learning: 2025-11-25T14:39:08.150Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-11-25T14:39:08.150Z
Learning: Applies to apps/web/app/api/**/*.{ts,tsx} : Request bodies should use Zod schemas for validation to ensure type safety and prevent injection attacks
Applied to files:
apps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsxapps/web/utils/actions/follow-up-reminders.validation.ts
📚 Learning: 2025-11-25T14:39:23.326Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-11-25T14:39:23.326Z
Learning: Applies to app/api/**/*.ts : All input parameters must be validated - check for presence, type, and format before use; use Zod schemas to validate request bodies with type guards and constraints
Applied to files:
apps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsxapps/web/utils/actions/follow-up-reminders.validation.ts
📚 Learning: 2025-11-25T14:42:08.869Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/ultracite.mdc:0-0
Timestamp: 2025-11-25T14:42:08.869Z
Learning: Applies to **/*.{js,jsx,ts,tsx} : Make sure label elements have text content and are associated with an input
Applied to files:
apps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsx
📚 Learning: 2025-11-25T14:42:08.869Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/ultracite.mdc:0-0
Timestamp: 2025-11-25T14:42:08.869Z
Learning: Applies to **/*.{js,jsx,ts,tsx} : Make sure anchors have content that's accessible to screen readers
Applied to files:
apps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsx
📚 Learning: 2025-11-25T14:42:08.869Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/ultracite.mdc:0-0
Timestamp: 2025-11-25T14:42:08.869Z
Learning: Applies to **/*.{js,jsx,ts,tsx} : Give all elements requiring alt text meaningful information for screen readers
Applied to files:
apps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsx
📚 Learning: 2025-11-25T14:42:08.869Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/ultracite.mdc:0-0
Timestamp: 2025-11-25T14:42:08.869Z
Learning: Applies to **/*.{js,jsx,ts,tsx} : Give heading elements content that's accessible to screen readers (not hidden with `aria-hidden`)
Applied to files:
apps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsx
📚 Learning: 2025-11-25T14:42:08.869Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/ultracite.mdc:0-0
Timestamp: 2025-11-25T14:42:08.869Z
Learning: Applies to **/*.{js,jsx,ts,tsx} : Don't assign non-interactive ARIA roles to interactive HTML elements
Applied to files:
apps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsx
📚 Learning: 2025-11-25T14:42:08.869Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/ultracite.mdc:0-0
Timestamp: 2025-11-25T14:42:08.869Z
Learning: Applies to **/*.{js,jsx,ts,tsx} : Don't set `aria-hidden="true"` on focusable elements
Applied to files:
apps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsx
📚 Learning: 2025-11-25T14:42:08.869Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/ultracite.mdc:0-0
Timestamp: 2025-11-25T14:42:08.869Z
Learning: Applies to **/*.{js,jsx,ts,tsx} : Use valid ARIA state and property values
Applied to files:
apps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsx
📚 Learning: 2025-11-25T14:42:08.869Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/ultracite.mdc:0-0
Timestamp: 2025-11-25T14:42:08.869Z
Learning: Applies to **/*.{js,jsx,ts,tsx} : Use valid, non-abstract ARIA roles for elements with ARIA roles
Applied to files:
apps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsx
📚 Learning: 2025-11-25T14:42:08.869Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/ultracite.mdc:0-0
Timestamp: 2025-11-25T14:42:08.869Z
Learning: Applies to **/*.{js,jsx,ts,tsx} : Don't assign interactive ARIA roles to non-interactive HTML elements
Applied to files:
apps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsx
📚 Learning: 2025-11-25T14:42:08.869Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/ultracite.mdc:0-0
Timestamp: 2025-11-25T14:42:08.869Z
Learning: Applies to **/*.{js,jsx,ts,tsx} : Make static elements with click handlers use a valid role attribute
Applied to files:
apps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsx
📚 Learning: 2026-01-07T21:07:06.691Z
Learnt from: elie222
Repo: elie222/inbox-zero PR: 1230
File: apps/web/app/(app)/[emailAccountId]/drive/page.tsx:47-70
Timestamp: 2026-01-07T21:07:06.691Z
Learning: In TSX files across the codebase, prefer direct server action calls with manual error handling (e.g., check result?.serverError and handle errors explicitly). The useAction hook pattern is not required; you can call server actions directly and use try/finally to ensure cleanup (such as resetting loading states) regardless of the hook. Apply consistently for components that perform server interactions.
Applied to files:
apps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsx
📚 Learning: 2026-01-09T17:27:19.225Z
Learnt from: elie222
Repo: elie222/inbox-zero PR: 1234
File: apps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsx:65-83
Timestamp: 2026-01-09T17:27:19.225Z
Learning: In the elie222/inbox-zero repo, for React components using next-safe-action, using optimistic updates with mutate on success/error is an accepted approach to address race conditions in toggle handlers. It is acceptable for components not to guard rapid toggles with isExecuting (disable) when the optimistic UI state is reconciled by mutate. Apply this guidance to similar TSX components in the web app where appropriate.
Applied to files:
apps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsx
📚 Learning: 2025-11-25T14:37:22.660Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-11-25T14:37:22.660Z
Learning: Applies to **/*.{ts,tsx} : Use wrapper functions for Gmail thread operations from @/utils/gmail/thread.ts instead of direct API calls
Applied to files:
apps/web/app/api/follow-up-reminders/process.ts
📚 Learning: 2025-11-25T14:37:22.660Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-11-25T14:37:22.660Z
Learning: Applies to **/*.{ts,tsx} : Use wrapper functions for Gmail label operations from @/utils/gmail/label.ts instead of direct API calls
Applied to files:
apps/web/app/api/follow-up-reminders/process.ts
📚 Learning: 2025-11-25T14:37:22.660Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-11-25T14:37:22.660Z
Learning: Applies to **/*.{ts,tsx} : Use wrapper functions for Gmail message operations (get, list, batch, etc.) from @/utils/gmail/message.ts instead of direct API calls
Applied to files:
apps/web/app/api/follow-up-reminders/process.ts
📚 Learning: 2025-11-25T14:38:07.606Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/llm.mdc:0-0
Timestamp: 2025-11-25T14:38:07.606Z
Learning: Applies to apps/web/utils/ai/**/*.ts : Use descriptive scoped loggers for each LLM feature, log inputs and outputs with appropriate log levels, and include relevant context in log messages
Applied to files:
apps/web/app/api/follow-up-reminders/process.ts
📚 Learning: 2025-11-25T14:37:22.660Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-11-25T14:37:22.660Z
Learning: Applies to apps/web/utils/gmail/**/*.{ts,tsx} : Keep Gmail provider-specific implementation details isolated within the apps/web/utils/gmail/ directory
Applied to files:
apps/web/app/api/follow-up-reminders/process.ts
📚 Learning: 2025-11-25T14:38:07.606Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/llm.mdc:0-0
Timestamp: 2025-11-25T14:38:07.606Z
Learning: Applies to apps/web/utils/ai/**/*.ts : Keep related AI functions in the same file or directory, extract common patterns into utility functions, and document complex AI logic with clear comments
Applied to files:
apps/web/app/api/follow-up-reminders/process.ts
📚 Learning: 2025-11-25T14:39:49.448Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/server-actions.mdc:0-0
Timestamp: 2025-11-25T14:39:49.448Z
Learning: Applies to apps/web/utils/actions/*.validation.ts : Define input validation schemas using Zod in `.validation.ts` files and export both the schema and its inferred TypeScript type
Applied to files:
apps/web/utils/actions/follow-up-reminders.validation.ts
📚 Learning: 2025-11-25T14:36:51.389Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/form-handling.mdc:0-0
Timestamp: 2025-11-25T14:36:51.389Z
Learning: Applies to **/*.validation.ts : Define validation schemas using Zod
Applied to files:
apps/web/utils/actions/follow-up-reminders.validation.ts
📚 Learning: 2025-11-25T14:39:27.909Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-11-25T14:39:27.909Z
Learning: Applies to **/app/api/**/*.ts : Always validate request bodies using Zod schemas to ensure type safety and prevent invalid data from reaching database operations
Applied to files:
apps/web/utils/actions/follow-up-reminders.validation.ts
📚 Learning: 2025-11-25T14:36:53.147Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/form-handling.mdc:0-0
Timestamp: 2025-11-25T14:36:53.147Z
Learning: Applies to **/*.validation.{ts,tsx} : Define validation schemas using Zod
Applied to files:
apps/web/utils/actions/follow-up-reminders.validation.ts
📚 Learning: 2025-11-25T14:39:04.892Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-11-25T14:39:04.892Z
Learning: Applies to apps/web/app/api/**/route.ts : Use Zod schemas for request body validation in API routes
Applied to files:
apps/web/utils/actions/follow-up-reminders.validation.ts
🧬 Code graph analysis (3)
apps/web/utils/actions/follow-up-reminders.ts (4)
apps/web/utils/actions/safe-action.ts (1)
actionClient(84-138)apps/web/utils/actions/follow-up-reminders.validation.ts (3)
toggleFollowUpRemindersBody(5-7)DEFAULT_FOLLOW_UP_DAYS(3-3)saveFollowUpSettingsBody(14-18)apps/web/utils/error.ts (1)
SafeError(88-98)apps/web/app/api/follow-up-reminders/process.ts (1)
processAccountFollowUps(93-199)
apps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsx (8)
apps/web/hooks/useFeatureFlags.ts (1)
useFollowUpRemindersEnabled(12-17)apps/web/utils/actions/follow-up-reminders.ts (3)
toggleFollowUpRemindersAction(14-25)updateFollowUpSettingsAction(27-48)scanFollowUpRemindersAction(50-81)apps/web/components/Toast.tsx (2)
toastError(14-19)toastSuccess(3-12)apps/web/utils/actions/follow-up-reminders.validation.ts (2)
DEFAULT_FOLLOW_UP_DAYS(3-3)SaveFollowUpSettingsFormInput(26-28)apps/web/components/SettingCard.tsx (1)
SettingCard(3-34)apps/web/components/ui/dialog.tsx (6)
Dialog(116-116)DialogTrigger(120-120)DialogContent(121-121)DialogHeader(122-122)DialogTitle(124-124)DialogDescription(125-125)apps/web/components/Toggle.tsx (1)
Toggle(18-50)apps/web/providers/EmailAccountProvider.tsx (1)
useAccount(79-89)
apps/web/app/api/follow-up-reminders/process.ts (8)
apps/web/utils/logger.ts (1)
Logger(6-6)apps/web/utils/premium/index.ts (1)
getPremiumUserFilter(145-158)apps/web/utils/error.ts (1)
captureException(47-77)apps/web/utils/llms/types.ts (1)
EmailAccountWithAI(10-32)apps/web/utils/follow-up/labels.ts (2)
getOrCreateFollowUpLabel(6-16)applyFollowUpLabel(18-42)apps/web/utils/follow-up/cleanup.ts (1)
cleanupStaleDrafts(9-90)apps/web/utils/email/types.ts (1)
EmailProvider(45-251)apps/web/utils/follow-up/generate-draft.ts (1)
generateFollowUpDraft(10-54)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: cubic · AI code reviewer
- GitHub Check: test
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (18)
apps/web/prisma/migrations/20260111000000_add_follow_up_reminders/migration.sql (1)
1-7: LGTM!The migration correctly adds the follow-up reminder columns to
EmailAccountand tracking timestamp toThreadTracker. The nullable integers for days thresholds and the non-null boolean with a sensible default align well with the feature's opt-in nature.apps/web/prisma/schema.prisma (2)
148-151: LGTM!The follow-up settings fields are well-designed: nullable integers allow users to selectively enable awaiting/needs-reply reminders independently, and the boolean defaults to
truefor auto-draft generation.
755-756: Good index design for query performance.The new
followUpAppliedAtfield enables idempotent processing (preventing re-processing of already-labeled threads). The composite index@@index([emailAccountId, type, resolved, followUpAppliedAt, sentAt])directly supports the query pattern inprocess.tsthat filters by these exact columns.Also applies to: 764-764
apps/web/utils/actions/follow-up-reminders.ts (4)
1-13: LGTM!Proper
'use server'directive and clean imports following project conventions. The actions correctly useactionClientwhich handles authentication and ownership validation.
14-25: LGTM!The toggle action correctly uses
DEFAULT_FOLLOW_UP_DAYSto enable reminders andnullto disable them, allowing independent control of awaiting vs needs-reply settings in the future.
27-48: LGTM!The update action properly accepts nullable day values and the auto-draft boolean, delegating ownership validation to
actionClient.
50-81: LGTM!The scan action correctly:
- Uses
z.object({})for empty input validation- Fetches the full account with AI settings needed for draft generation
- Throws
SafeErrorfor missing accounts (user-friendly error)- Delegates to
processAccountFollowUpswith proper logger contextapps/web/app/(app)/[emailAccountId]/assistant/settings/FollowUpRemindersSetting.tsx (4)
34-40: LGTM!Clean feature flag guard pattern using
useFollowUpRemindersEnabled()hook, preventing feature exposure when disabled.
50-75: LGTM!Good implementation of optimistic updates with proper error recovery via
mutate(). The pattern follows the established approach in this codebase where optimistic UI state is reconciled by mutate on error. Based on learnings, this is the accepted approach for toggle handlers.
177-187: LGTM!The string-to-number conversion correctly handles empty strings as
null, aligning with the server-side schema that expects nullable numbers.
228-245: LGTM!The auto-draft toggle correctly uses
watchandsetValueto integrate with react-hook-form state, maintaining form consistency.apps/web/utils/actions/follow-up-reminders.validation.ts (1)
1-28: LGTM!Well-structured validation module following project conventions:
- Separate schemas for server action (
saveFollowUpSettingsBodywith numbers) and form input (saveFollowUpSettingsFormBodywith strings)- Exported types using
z.inferpattern- Nullable
daysSchemaallows disabling individual reminder types- The 0.001 minimum allows sub-day thresholds (useful for testing)
apps/web/app/api/follow-up-reminders/process.ts (6)
18-53: LGTM!The batch query correctly:
- Filters for accounts with at least one follow-up setting enabled via
ORcondition- Applies premium user filter to restrict to paying users
- Selects all fields needed for AI draft generation and provider initialization
60-78: LGTM!Good error isolation pattern: each account is processed independently, errors are logged with account context, and
captureExceptionreports to Sentry without blocking other accounts.
93-152: LGTM!The AWAITING tracker flow is well-structured:
- Early return for missing provider prevents downstream errors
- Threshold calculation uses
subDayscorrectly- Query includes
followUpAppliedAt: nullto prevent re-processing- Draft generation is conditional on
followUpAutoDraftEnabled
154-184: LGTM!NEEDS_REPLY processing mirrors AWAITING but correctly disables draft generation (
generateDraft: false) since drafts are only useful when waiting for external replies.
186-199: LGTM!Non-critical cleanup wrapped in try/catch ensures label application and draft generation succeed even if cleanup fails. Error is still captured for monitoring.
201-266: LGTM!The
processTrackershelper is well-designed:
- Per-tracker logging context via
logger.with()- Error isolation per tracker (one failure doesn't stop others)
- Atomic update of
followUpAppliedAtafter successful label/draft operations- Clear metrics logged at completion
The tracker update at line 246-249 is secure because the trackers were already fetched with
emailAccountIdfilter in lines 127-135 and 159-167.
User description
Summary by CodeRabbit
Release Notes
New Features
Bug Fixes
Tests
✏️ Tip: You can customize this high-level summary in your review settings.
Generated description
Below is a concise technical summary of the changes proposed in this PR:
graph LR FollowUpRemindersSetting_("FollowUpRemindersSetting"):::added scanFollowUpRemindersAction_("scanFollowUpRemindersAction"):::added processAccountFollowUps_("processAccountFollowUps"):::added processAllFollowUpReminders_("processAllFollowUpReminders"):::added processTrackers_("processTrackers"):::added cleanupStaleDrafts_("cleanupStaleDrafts"):::added applyFollowUpLabel_("applyFollowUpLabel"):::added generateFollowUpDraft_("generateFollowUpDraft"):::added DB_emailAccount_("DB: emailAccount"):::modified DB_threadTracker_("DB: threadTracker"):::modified FollowUpRemindersSetting_ -- "Triggers immediate scan for follow-up reminders via action." --> scanFollowUpRemindersAction_ scanFollowUpRemindersAction_ -- "Invokes account follow-up processing for this email account." --> processAccountFollowUps_ processAllFollowUpReminders_ -- "Iterates accounts and runs per-account follow-up processing." --> processAccountFollowUps_ processAccountFollowUps_ -- "Delegates tracker batches for labeling and optional drafting." --> processTrackers_ processAccountFollowUps_ -- "Cleans up stale generated follow-up drafts post-processing." --> cleanupStaleDrafts_ processTrackers_ -- "Applies 'Follow-up' label to thread via provider." --> applyFollowUpLabel_ processTrackers_ -- "Generates draft nudges for threads when enabled." --> generateFollowUpDraft_ processAllFollowUpReminders_ -- "Queries enabled premium email accounts for follow-up processing." --> DB_emailAccount_ processTrackers_ -- "Updates threadTracker.followUpAppliedAt to mark processed trackers." --> DB_threadTracker_ classDef added stroke:#15AA7A classDef removed stroke:#CD5270 classDef modified stroke:#EDAC4C linkStyle default stroke:#CBD5E1,font-size:13pxImplement an automated email follow-up reminder system, allowing users to configure thresholds for unreplied messages and automatically apply a 'Follow-up' label or generate draft replies. Integrate this new functionality into the
EmailAccountmodel and existing email processing flows, providing a user interface for settings management and ensuring proper feature flagging.Modified files (4)
Latest Contributors(1)
Modified files (5)
Latest Contributors(2)
Modified files (6)
Latest Contributors(2)
Modified files (10)
Latest Contributors(0)