Outlook refactor & Delayed Actions fixes#595
Conversation
|
@edulelis is attempting to deploy a commit to the Inbox Zero Team on Vercel. A member of the Team first needs to authorize it. |
|
Caution Review failedThe pull request is closed. WalkthroughThis set of changes refactors email message parsing and thread reply detection throughout the codebase. It moves Gmail-specific parsing logic from a generic mail utility to a Gmail-dedicated module, introduces a provider-agnostic Changes
Sequence Diagram(s)sequenceDiagram
participant API as API Endpoint
participant Provider as EmailProvider
participant Gmail as GmailProvider
participant Outlook as OutlookProvider
API->>Provider: createEmailProvider(type, accountId)
alt Gmail
Provider->>Gmail: getMessage(messageId)
Gmail-->>Provider: ParsedMessage
else Outlook
Provider->>Outlook: getMessage(messageId)
Outlook-->>Provider: ParsedMessage
end
API->>Provider: isReplyInThread(ParsedMessage)
Provider-->>API: true/false
Estimated code review effort🎯 4 (Complex) | ⏱️ ~40 minutes Possibly related PRs
Poem
Note ⚡️ Unit Test Generation is now available in beta!Learn more here, or try it out under "Finishing Touches" below. 📜 Recent review detailsConfiguration used: .coderabbit.yaml 📒 Files selected for processing (1)
✨ Finishing Touches
🧪 Generate unit tests
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
| return result; | ||
| } | ||
|
|
||
| export function parseMessages( |
There was a problem hiding this comment.
This is Gmail only.
When moved to the Gmail folder, it prompted many refactors.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🔭 Outside diff range comments (1)
apps/web/app/api/google/threads/controller.ts (1)
78-93: Batch Redis look-ups to eliminate N+1 latency
getCategoryis invoked once per thread inside anasyncmap, producing as many round-trips to Redis as there are threads. For large pages (50 threads) this quickly dominates response time. Consider a batched helper (e.g.getCategoriesBatch(emailAccountId, threadIds)) that pipelines/MGETs all keys in one call and returns a map.- category: await getCategory({ emailAccountId, threadId: id }), + category: categoriesMap.get(id),where
categoriesMapis obtained once before thePromise.all:const categoriesMap = await getCategoriesBatch(emailAccountId, threadIds);
🧹 Nitpick comments (6)
apps/web/app/(app)/[emailAccountId]/simple/page.tsx (1)
47-52: N + 1 API calls – consider batching to reduce latency
Promise.all(filteredMessages.map(async (message) => getMessage(...)))issues one HTTP call per message.
IffilteredMessages.length> 5 this page can become sluggish.Suggestion: use the existing batch util (
getBatch) or Gmail’s/batchendpoint to fetch all messages in one request before parsing.apps/web/app/api/user/rules/[id]/example/controller.ts (1)
2-3: Consolidate duplicate imports from the same moduleHaving two separate
importstatements that pull different names from the same file is redundant and slightly hurts readability. Combine them:-import { parseMessage } from "@/utils/gmail/message"; -import { getMessage, getMessages } from "@/utils/gmail/message"; +import { parseMessage, getMessage, getMessages } from "@/utils/gmail/message";apps/web/utils/actions/user.ts (1)
9-10: Merge adjacent imports from the same pathLines 9-10 import from the identical module twice. Collapsing to a single statement avoids noise:
-import { getMessage, getMessages } from "@/utils/gmail/message"; -import { parseMessage } from "@/utils/gmail/message"; +import { getMessage, getMessages, parseMessage } from "@/utils/gmail/message";apps/web/app/api/user/planned/get-executed-rules.ts (1)
1-3: Deduplicate import lines
parseMessage,getMessagecome from the same file but are imported in two separate statements. Prefer a single import for clarity:-import { parseMessage } from "@/utils/gmail/message"; -… -import { getMessage } from "@/utils/gmail/message"; +import { parseMessage, getMessage } from "@/utils/gmail/message";apps/web/app/api/user/stats/recipients/route.ts (1)
6-7: Collapse duplicate importsSame module, two lines. Combine:
-import { parseMessage } from "@/utils/gmail/message"; -import { getMessage, getMessages } from "@/utils/gmail/message"; +import { parseMessage, getMessage, getMessages } from "@/utils/gmail/message";apps/web/utils/types.ts (1)
3-3: Remove unrelated import.The import of
metadatafrom"../app/layout"appears to be unrelated to the type definitions in this file and may have been added accidentally during the refactoring.-import { metadata } from "../app/layout";
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (27)
README.md(2 hunks)apps/web/app/(app)/[emailAccountId]/simple/page.tsx(1 hunks)apps/web/app/api/clean/route.ts(1 hunks)apps/web/app/api/google/threads/controller.ts(1 hunks)apps/web/app/api/google/webhook/process-history-item.ts(1 hunks)apps/web/app/api/outlook/webhook/process-history-item.ts(3 hunks)apps/web/app/api/user/group/[groupId]/messages/controller.ts(1 hunks)apps/web/app/api/user/no-reply/route.ts(1 hunks)apps/web/app/api/user/planned/get-executed-rules.ts(1 hunks)apps/web/app/api/user/rules/[id]/example/controller.ts(1 hunks)apps/web/app/api/user/stats/recipients/route.ts(1 hunks)apps/web/utils/actions/ai-rule.ts(1 hunks)apps/web/utils/actions/user.ts(1 hunks)apps/web/utils/ai/actions.ts(3 hunks)apps/web/utils/ai/choose-rule/match-rules.ts(1 hunks)apps/web/utils/email/provider.ts(4 hunks)apps/web/utils/gmail/draft.ts(1 hunks)apps/web/utils/gmail/mail.ts(1 hunks)apps/web/utils/gmail/message.ts(2 hunks)apps/web/utils/gmail/thread.ts(1 hunks)apps/web/utils/mail.ts(1 hunks)apps/web/utils/outlook/draft.ts(1 hunks)apps/web/utils/outlook/message.ts(6 hunks)apps/web/utils/scheduled-actions/executor.test.ts(4 hunks)apps/web/utils/scheduled-actions/executor.ts(0 hunks)apps/web/utils/thread.ts(1 hunks)apps/web/utils/types.ts(3 hunks)
💤 Files with no reviewable changes (1)
- apps/web/utils/scheduled-actions/executor.ts
🧰 Additional context used
📓 Path-based instructions (29)
apps/web/**/*.{ts,tsx}
📄 CodeRabbit Inference Engine (apps/web/CLAUDE.md)
apps/web/**/*.{ts,tsx}: Use TypeScript with strict null checks
Path aliases: Use@/for imports from project root
Use proper error handling with try/catch blocks
Format code with Prettier
Leverage TypeScript inference for better DX
Files:
apps/web/app/api/user/no-reply/route.tsapps/web/utils/outlook/draft.tsapps/web/utils/gmail/thread.tsapps/web/app/api/user/stats/recipients/route.tsapps/web/app/api/user/rules/[id]/example/controller.tsapps/web/utils/actions/ai-rule.tsapps/web/app/api/google/threads/controller.tsapps/web/app/api/google/webhook/process-history-item.tsapps/web/utils/actions/user.tsapps/web/app/api/user/planned/get-executed-rules.tsapps/web/app/(app)/[emailAccountId]/simple/page.tsxapps/web/utils/gmail/mail.tsapps/web/utils/gmail/draft.tsapps/web/app/api/clean/route.tsapps/web/utils/ai/actions.tsapps/web/utils/ai/choose-rule/match-rules.tsapps/web/utils/scheduled-actions/executor.test.tsapps/web/utils/mail.tsapps/web/app/api/outlook/webhook/process-history-item.tsapps/web/app/api/user/group/[groupId]/messages/controller.tsapps/web/utils/thread.tsapps/web/utils/gmail/message.tsapps/web/utils/email/provider.tsapps/web/utils/types.tsapps/web/utils/outlook/message.ts
apps/web/app/**
📄 CodeRabbit Inference Engine (apps/web/CLAUDE.md)
NextJS app router structure with (app) directory
Files:
apps/web/app/api/user/no-reply/route.tsapps/web/app/api/user/stats/recipients/route.tsapps/web/app/api/user/rules/[id]/example/controller.tsapps/web/app/api/google/threads/controller.tsapps/web/app/api/google/webhook/process-history-item.tsapps/web/app/api/user/planned/get-executed-rules.tsapps/web/app/(app)/[emailAccountId]/simple/page.tsxapps/web/app/api/clean/route.tsapps/web/app/api/outlook/webhook/process-history-item.tsapps/web/app/api/user/group/[groupId]/messages/controller.ts
apps/web/app/api/**/route.ts
📄 CodeRabbit Inference Engine (apps/web/CLAUDE.md)
apps/web/app/api/**/route.ts: UsewithAuthfor user-level operations
UsewithEmailAccountfor email-account-level operations
Do NOT use POST API routes for mutations - use server actions instead
No need for try/catch in GET routes when using middleware
Export response types from GET routes
apps/web/app/api/**/route.ts: Wrap all GET API route handlers withwithAuthorwithEmailAccountmiddleware for authentication and authorization.
Export response types from GET API routes for type-safe client usage.
Do not use try/catch in GET API routes when using authentication middleware; rely on centralized error handling.
Files:
apps/web/app/api/user/no-reply/route.tsapps/web/app/api/user/stats/recipients/route.tsapps/web/app/api/clean/route.ts
!{.cursor/rules/*.mdc}
📄 CodeRabbit Inference Engine (.cursor/rules/cursor-rules.mdc)
Never place rule files in the project root, in subdirectories outside .cursor/rules, or in any other location
Files:
apps/web/app/api/user/no-reply/route.tsapps/web/utils/outlook/draft.tsapps/web/utils/gmail/thread.tsapps/web/app/api/user/stats/recipients/route.tsapps/web/app/api/user/rules/[id]/example/controller.tsapps/web/utils/actions/ai-rule.tsapps/web/app/api/google/threads/controller.tsapps/web/app/api/google/webhook/process-history-item.tsapps/web/utils/actions/user.tsapps/web/app/api/user/planned/get-executed-rules.tsapps/web/app/(app)/[emailAccountId]/simple/page.tsxapps/web/utils/gmail/mail.tsapps/web/utils/gmail/draft.tsapps/web/app/api/clean/route.tsapps/web/utils/ai/actions.tsapps/web/utils/ai/choose-rule/match-rules.tsapps/web/utils/scheduled-actions/executor.test.tsREADME.mdapps/web/utils/mail.tsapps/web/app/api/outlook/webhook/process-history-item.tsapps/web/app/api/user/group/[groupId]/messages/controller.tsapps/web/utils/thread.tsapps/web/utils/gmail/message.tsapps/web/utils/email/provider.tsapps/web/utils/types.tsapps/web/utils/outlook/message.ts
**/*.ts
📄 CodeRabbit Inference Engine (.cursor/rules/form-handling.mdc)
**/*.ts: The same validation should be done in the server action too
Define validation schemas using Zod
Files:
apps/web/app/api/user/no-reply/route.tsapps/web/utils/outlook/draft.tsapps/web/utils/gmail/thread.tsapps/web/app/api/user/stats/recipients/route.tsapps/web/app/api/user/rules/[id]/example/controller.tsapps/web/utils/actions/ai-rule.tsapps/web/app/api/google/threads/controller.tsapps/web/app/api/google/webhook/process-history-item.tsapps/web/utils/actions/user.tsapps/web/app/api/user/planned/get-executed-rules.tsapps/web/utils/gmail/mail.tsapps/web/utils/gmail/draft.tsapps/web/app/api/clean/route.tsapps/web/utils/ai/actions.tsapps/web/utils/ai/choose-rule/match-rules.tsapps/web/utils/scheduled-actions/executor.test.tsapps/web/utils/mail.tsapps/web/app/api/outlook/webhook/process-history-item.tsapps/web/app/api/user/group/[groupId]/messages/controller.tsapps/web/utils/thread.tsapps/web/utils/gmail/message.tsapps/web/utils/email/provider.tsapps/web/utils/types.tsapps/web/utils/outlook/message.ts
**/*.{ts,tsx}
📄 CodeRabbit Inference Engine (.cursor/rules/logging.mdc)
**/*.{ts,tsx}: UsecreateScopedLoggerfor logging in backend TypeScript files
Typically add the logger initialization at the top of the file when usingcreateScopedLogger
Only use.with()on a logger instance within a specific function, not for a global loggerImport Prisma in the project using
import prisma from "@/utils/prisma";
**/*.{ts,tsx}: Don't use TypeScript enums.
Don't use TypeScript const enum.
Don't use the TypeScript directive @ts-ignore.
Don't use primitive type aliases or misleading types.
Don't use empty type parameters in type aliases and interfaces.
Don't use any or unknown as type constraints.
Don't use implicit any type on variable declarations.
Don't let variables evolve into any type through reassignments.
Don't use non-null assertions with the ! postfix operator.
Don't misuse the non-null assertion operator (!) in TypeScript files.
Don't use user-defined types.
Use as const instead of literal types and type annotations.
Use export type for types.
Use import type for types.
Don't declare empty interfaces.
Don't merge interfaces and classes unsafely.
Don't use overload signatures that aren't next to each other.
Use the namespace keyword instead of the module keyword to declare TypeScript namespaces.
Don't use TypeScript namespaces.
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 parameter properties in class constructors.
Use either T[] or Array consistently.
Initialize each enum member value explicitly.
Make sure all enum members are literal values.
Files:
apps/web/app/api/user/no-reply/route.tsapps/web/utils/outlook/draft.tsapps/web/utils/gmail/thread.tsapps/web/app/api/user/stats/recipients/route.tsapps/web/app/api/user/rules/[id]/example/controller.tsapps/web/utils/actions/ai-rule.tsapps/web/app/api/google/threads/controller.tsapps/web/app/api/google/webhook/process-history-item.tsapps/web/utils/actions/user.tsapps/web/app/api/user/planned/get-executed-rules.tsapps/web/app/(app)/[emailAccountId]/simple/page.tsxapps/web/utils/gmail/mail.tsapps/web/utils/gmail/draft.tsapps/web/app/api/clean/route.tsapps/web/utils/ai/actions.tsapps/web/utils/ai/choose-rule/match-rules.tsapps/web/utils/scheduled-actions/executor.test.tsapps/web/utils/mail.tsapps/web/app/api/outlook/webhook/process-history-item.tsapps/web/app/api/user/group/[groupId]/messages/controller.tsapps/web/utils/thread.tsapps/web/utils/gmail/message.tsapps/web/utils/email/provider.tsapps/web/utils/types.tsapps/web/utils/outlook/message.ts
**/api/**/route.ts
📄 CodeRabbit Inference Engine (.cursor/rules/security.mdc)
**/api/**/route.ts: ALL API routes that handle user data MUST use appropriate authentication and authorization middleware (withAuth or withEmailAccount).
ALL database queries in API routes MUST be scoped to the authenticated user/account (e.g., include userId or emailAccountId in query filters).
Always validate that resources belong to the authenticated user before performing operations (resource ownership validation).
UsewithEmailAccountmiddleware for API routes that operate on a specific email account (i.e., use or requireemailAccountId).
UsewithAuthmiddleware for API routes that operate at the user level (i.e., use or require onlyuserId).
UsewithErrormiddleware (with proper validation) for public endpoints, custom authentication, or cron endpoints.
Cron endpoints MUST usewithErrormiddleware and validate the cron secret usinghasCronSecret(request)orhasPostCronSecret(request).
Cron endpoints MUST capture unauthorized attempts withcaptureExceptionand return a 401 status for unauthorized requests.
All parameters in API routes MUST be validated for type, format, and length before use.
Request bodies in API routes MUST be validated using Zod schemas before use.
All Prisma queries in API routes MUST only return necessary fields and never expose sensitive data.
Error messages in API routes MUST not leak internal information or sensitive data; use generic error messages and SafeError where appropriate.
API routes MUST use a consistent error response format, returning JSON with an error message and status code.
AllfindUniqueandfindFirstPrisma calls in API routes MUST include ownership filters (e.g., userId or emailAccountId).
AllfindManyPrisma calls in API routes MUST be scoped to the authenticated user's data.
Never use direct object references in API routes without ownership checks (prevent IDOR vulnerabilities).
Prevent mass assignment vulnerabilities by only allowing explicitly whitelisted fields in update operations in AP...
Files:
apps/web/app/api/user/no-reply/route.tsapps/web/app/api/user/stats/recipients/route.tsapps/web/app/api/clean/route.ts
apps/web/app/api/**/*.{ts,js}
📄 CodeRabbit Inference Engine (.cursor/rules/security-audit.mdc)
apps/web/app/api/**/*.{ts,js}: All API route handlers in 'apps/web/app/api/' must use authentication middleware: withAuth, withEmailAccount, or withError (with custom authentication logic).
All Prisma queries in API routes must include user/account filtering (e.g., emailAccountId or userId in WHERE clauses) to prevent unauthorized data access.
All parameters used in API routes must be validated before use; do not use parameters from 'params' or request bodies directly in queries without validation.
Request bodies in API routes should use Zod schemas for validation.
API routes should only return necessary fields using Prisma's 'select' and must not include sensitive data in error messages.
Error messages in API routes must not reveal internal details; use generic errors and SafeError for user-facing errors.
All QStash endpoints (API routes called via publishToQstash or publishToQstashQueue) must use verifySignatureAppRouter to verify request authenticity.
All cron endpoints in API routes must use hasCronSecret or hasPostCronSecret for authentication.
Do not hardcode weak or plaintext secrets in API route files; secrets must not be directly assigned as string literals.
Review all new withError usage in API routes to ensure custom authentication is implemented where required.
Files:
apps/web/app/api/user/no-reply/route.tsapps/web/app/api/user/stats/recipients/route.tsapps/web/app/api/user/rules/[id]/example/controller.tsapps/web/app/api/google/threads/controller.tsapps/web/app/api/google/webhook/process-history-item.tsapps/web/app/api/user/planned/get-executed-rules.tsapps/web/app/api/clean/route.tsapps/web/app/api/outlook/webhook/process-history-item.tsapps/web/app/api/user/group/[groupId]/messages/controller.ts
**/*.{js,jsx,ts,tsx}
📄 CodeRabbit Inference Engine (.cursor/rules/ultracite.mdc)
**/*.{js,jsx,ts,tsx}: Don't useelements in Next.js projects.
Don't use elements in Next.js projects.
Don't use namespace imports.
Don't access namespace imports dynamically.
Don't use global eval().
Don't use console.
Don't use debugger.
Don't use var.
Don't use with statements in non-strict contexts.
Don't use the arguments object.
Don't use consecutive spaces in regular expression literals.
Don't use the comma operator.
Don't use unnecessary boolean casts.
Don't use unnecessary callbacks with flatMap.
Use for...of statements instead of Array.forEach.
Don't create classes that only have static members (like a static namespace).
Don't use this and super in static contexts.
Don't use unnecessary catch clauses.
Don't use unnecessary constructors.
Don't use unnecessary continue statements.
Don't export empty modules that don't change anything.
Don't use unnecessary escape sequences in regular expression literals.
Don't use unnecessary labels.
Don't use unnecessary nested block statements.
Don't rename imports, exports, and destructured assignments to the same name.
Don't use unnecessary string or template literal concatenation.
Don't use String.raw in template literals when there are no escape sequences.
Don't use useless case statements in switch statements.
Don't use ternary operators when simpler alternatives exist.
Don't use useless this aliasing.
Don't initialize variables to undefined.
Don't use the void operators (they're not familiar).
Use arrow functions instead of function expressions.
Use Date.now() to get milliseconds since the Unix Epoch.
Use .flatMap() instead of map().flat() when possible.
Use literal property access instead of computed property access.
Don't use parseInt() or Number.parseInt() when binary, octal, or hexadecimal literals work.
Use concise optional chaining instead of chained logical expressions.
Use regular expression literals instead of the RegExp constructor when possible.
Don't use number literal object member names th...
Files:
apps/web/app/api/user/no-reply/route.tsapps/web/utils/outlook/draft.tsapps/web/utils/gmail/thread.tsapps/web/app/api/user/stats/recipients/route.tsapps/web/app/api/user/rules/[id]/example/controller.tsapps/web/utils/actions/ai-rule.tsapps/web/app/api/google/threads/controller.tsapps/web/app/api/google/webhook/process-history-item.tsapps/web/utils/actions/user.tsapps/web/app/api/user/planned/get-executed-rules.tsapps/web/app/(app)/[emailAccountId]/simple/page.tsxapps/web/utils/gmail/mail.tsapps/web/utils/gmail/draft.tsapps/web/app/api/clean/route.tsapps/web/utils/ai/actions.tsapps/web/utils/ai/choose-rule/match-rules.tsapps/web/utils/scheduled-actions/executor.test.tsapps/web/utils/mail.tsapps/web/app/api/outlook/webhook/process-history-item.tsapps/web/app/api/user/group/[groupId]/messages/controller.tsapps/web/utils/thread.tsapps/web/utils/gmail/message.tsapps/web/utils/email/provider.tsapps/web/utils/types.tsapps/web/utils/outlook/message.ts
!pages/_document.{js,jsx,ts,tsx}
📄 CodeRabbit Inference Engine (.cursor/rules/ultracite.mdc)
!pages/_document.{js,jsx,ts,tsx}: Don't import next/document outside of pages/_document.jsx in Next.js projects.
Don't import next/document outside of pages/_document.jsx in Next.js projects.
Files:
apps/web/app/api/user/no-reply/route.tsapps/web/utils/outlook/draft.tsapps/web/utils/gmail/thread.tsapps/web/app/api/user/stats/recipients/route.tsapps/web/app/api/user/rules/[id]/example/controller.tsapps/web/utils/actions/ai-rule.tsapps/web/app/api/google/threads/controller.tsapps/web/app/api/google/webhook/process-history-item.tsapps/web/utils/actions/user.tsapps/web/app/api/user/planned/get-executed-rules.tsapps/web/app/(app)/[emailAccountId]/simple/page.tsxapps/web/utils/gmail/mail.tsapps/web/utils/gmail/draft.tsapps/web/app/api/clean/route.tsapps/web/utils/ai/actions.tsapps/web/utils/ai/choose-rule/match-rules.tsapps/web/utils/scheduled-actions/executor.test.tsREADME.mdapps/web/utils/mail.tsapps/web/app/api/outlook/webhook/process-history-item.tsapps/web/app/api/user/group/[groupId]/messages/controller.tsapps/web/utils/thread.tsapps/web/utils/gmail/message.tsapps/web/utils/email/provider.tsapps/web/utils/types.tsapps/web/utils/outlook/message.ts
apps/web/utils/**
📄 CodeRabbit Inference Engine (.cursor/rules/project-structure.mdc)
Create utility functions in
utils/folder for reusable logic
Files:
apps/web/utils/outlook/draft.tsapps/web/utils/gmail/thread.tsapps/web/utils/actions/ai-rule.tsapps/web/utils/actions/user.tsapps/web/utils/gmail/mail.tsapps/web/utils/gmail/draft.tsapps/web/utils/ai/actions.tsapps/web/utils/ai/choose-rule/match-rules.tsapps/web/utils/scheduled-actions/executor.test.tsapps/web/utils/mail.tsapps/web/utils/thread.tsapps/web/utils/gmail/message.tsapps/web/utils/email/provider.tsapps/web/utils/types.tsapps/web/utils/outlook/message.ts
apps/web/utils/**/*.ts
📄 CodeRabbit Inference Engine (.cursor/rules/project-structure.mdc)
apps/web/utils/**/*.ts: Use lodash utilities for common operations (arrays, objects, strings)
Import specific lodash functions to minimize bundle size
Files:
apps/web/utils/outlook/draft.tsapps/web/utils/gmail/thread.tsapps/web/utils/actions/ai-rule.tsapps/web/utils/actions/user.tsapps/web/utils/gmail/mail.tsapps/web/utils/gmail/draft.tsapps/web/utils/ai/actions.tsapps/web/utils/ai/choose-rule/match-rules.tsapps/web/utils/scheduled-actions/executor.test.tsapps/web/utils/mail.tsapps/web/utils/thread.tsapps/web/utils/gmail/message.tsapps/web/utils/email/provider.tsapps/web/utils/types.tsapps/web/utils/outlook/message.ts
apps/web/utils/gmail/**/*.ts
📄 CodeRabbit Inference Engine (.cursor/rules/gmail-api.mdc)
Keep provider-specific implementation details isolated in the appropriate utils subfolder (e.g., 'apps/web/utils/gmail/')
Files:
apps/web/utils/gmail/thread.tsapps/web/utils/gmail/mail.tsapps/web/utils/gmail/draft.tsapps/web/utils/gmail/message.ts
apps/web/utils/actions/**/*.ts
📄 CodeRabbit Inference Engine (apps/web/CLAUDE.md)
apps/web/utils/actions/**/*.ts: Use server actions for all mutations (create/update/delete operations)
next-safe-actionprovides centralized error handling
Use Zod schemas for validation on both client and server
UserevalidatePathin server actions for cache invalidation
apps/web/utils/actions/**/*.ts: Use server actions (withnext-safe-action) for all mutations (create/update/delete operations); do NOT use POST API routes for mutations.
UserevalidatePathin server actions to invalidate cache after mutations.
Files:
apps/web/utils/actions/ai-rule.tsapps/web/utils/actions/user.ts
apps/web/utils/actions/*.ts
📄 CodeRabbit Inference Engine (.cursor/rules/server-actions.mdc)
apps/web/utils/actions/*.ts: Implement all server actions using thenext-safe-actionlibrary for type safety, input validation, context management, and error handling. Refer toapps/web/utils/actions/safe-action.tsfor client definitions (actionClient,actionClientUser,adminActionClient).
UseactionClientUserwhen only authenticated user context (userId) is needed.
UseactionClientwhen both authenticated user context and a specificemailAccountIdare needed. TheemailAccountIdmust be bound when calling the action from the client.
UseadminActionClientfor actions restricted to admin users.
Access necessary context (likeuserId,emailAccountId, etc.) provided by the safe action client via thectxobject in the.action()handler.
Server Actions are strictly for mutations (operations that change data, e.g., creating, updating, deleting). Do NOT use Server Actions for data fetching (GET operations). For data fetching, use dedicated GET API Routes combined with SWR Hooks.
UseSafeErrorfor expected/handled errors within actions if needed.next-safe-actionprovides centralized error handling.
Use the.metadata({ name: "actionName" })method to provide a meaningful name for monitoring. Sentry instrumentation is automatically applied viawithServerActionInstrumentationwithin the safe action clients.
If an action modifies data displayed elsewhere, userevalidatePathorrevalidateTagfromnext/cachewithin the action handler as needed.Server action files must start with
use server
Files:
apps/web/utils/actions/ai-rule.tsapps/web/utils/actions/user.ts
apps/web/**/*.tsx
📄 CodeRabbit Inference Engine (apps/web/CLAUDE.md)
apps/web/**/*.tsx: Follow tailwindcss patterns with prettier-plugin-tailwindcss
Prefer functional components with hooks
Use shadcn/ui components when available
Ensure responsive design with mobile-first approach
Follow consistent naming conventions (PascalCase for components)
Use LoadingContent component for async data
Useresult?.serverErrorwithtoastErrorandtoastSuccess
UseLoadingContentcomponent to handle loading and error states consistently
Passloading,error, and children props toLoadingContent
Files:
apps/web/app/(app)/[emailAccountId]/simple/page.tsx
**/*.tsx
📄 CodeRabbit Inference Engine (.cursor/rules/form-handling.mdc)
**/*.tsx: Use React Hook Form with Zod for validation
Validate form inputs before submission
Show validation errors inline next to form fields
Files:
apps/web/app/(app)/[emailAccountId]/simple/page.tsx
apps/web/app/(app)/*/**
📄 CodeRabbit Inference Engine (.cursor/rules/page-structure.mdc)
Components for the page are either put in page.tsx, or in the apps/web/app/(app)/PAGE_NAME folder
Files:
apps/web/app/(app)/[emailAccountId]/simple/page.tsx
apps/web/app/(app)/*/**/*.tsx
📄 CodeRabbit Inference Engine (.cursor/rules/page-structure.mdc)
If you need to use onClick in a component, that component is a client component and file must start with 'use client'
Files:
apps/web/app/(app)/[emailAccountId]/simple/page.tsx
apps/web/app/(app)/*/**/**/*.tsx
📄 CodeRabbit Inference Engine (.cursor/rules/page-structure.mdc)
If we're in a deeply nested component we will use swr to fetch via API
Files:
apps/web/app/(app)/[emailAccountId]/simple/page.tsx
apps/web/app/**/*.tsx
📄 CodeRabbit Inference Engine (.cursor/rules/project-structure.mdc)
Components with
onClickmust be client components withuse clientdirective
Files:
apps/web/app/(app)/[emailAccountId]/simple/page.tsx
**/*.{jsx,tsx}
📄 CodeRabbit Inference Engine (.cursor/rules/ultracite.mdc)
**/*.{jsx,tsx}: Don't destructure props inside JSX components in Solid projects.
Don't use both children and dangerouslySetInnerHTML props on the same element.
Don't use Array index in keys.
Don't assign to React component props.
Don't define React components inside other components.
Don't use event handlers on non-interactive elements.
Don't assign JSX properties multiple times.
Don't add extra closing tags for components without children.
Use <>...</> instead of ....
Don't insert comments as text nodes.
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 use unnecessary fragments.
Don't pass children as props.
Use semantic elements instead of role attributes in JSX.
Files:
apps/web/app/(app)/[emailAccountId]/simple/page.tsx
**/*.{html,jsx,tsx}
📄 CodeRabbit Inference Engine (.cursor/rules/ultracite.mdc)
**/*.{html,jsx,tsx}: Don't use or elements.
Don't use accessKey attribute on any HTML element.
Don't set aria-hidden="true" on focusable elements.
Don't add ARIA roles, states, and properties to elements that don't support them.
Only use the scope prop on 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 assign tabIndex to non-interactive HTML elements.
Don't use positive integers for tabIndex property.
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 a title element 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.
Assign tabIndex to non-interactive HTML elements with aria-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 a type attribute for button elements.
Make elements with interactive roles and handlers focusable.
Give heading elements content that's accessible to screen readers (not hidden with aria-hidden).
Always include a lang attribute on the html element.
Always include a title attribute for iframe elements.
Accompany onClick with at least one of: onKeyUp, onKeyDown, or onKeyPress.
Accompany onMouseOver/onMouseOut with onFocus/onBlur.
Include caption tracks for audio and video elements.
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 ARIA state and property values.
Use valid values for the autocomplete attribute on input eleme...Files:
apps/web/app/(app)/[emailAccountId]/simple/page.tsxapps/web/utils/{ai,llms}/**/*
📄 CodeRabbit Inference Engine (.cursor/rules/llm.mdc)
apps/web/utils/{ai,llms}/**/*: LLM-related code must be organized in the directories: apps/web/utils/ai/, apps/web/utils/llms/, and apps/web/tests/ for LLM-specific tests.
Keep related AI functions in the same file or directory.Files:
apps/web/utils/ai/actions.tsapps/web/utils/ai/choose-rule/match-rules.tsapps/web/utils/{ai,llms}/**/*.ts
📄 CodeRabbit Inference Engine (.cursor/rules/llm.mdc)
apps/web/utils/{ai,llms}/**/*.ts: Follow the standard structure for LLM-related functions: use a scoped logger, define a Zod schema for output, validate inputs early, separate system and user prompts, log inputs and outputs, call chatCompletionObject with proper configuration, and return validated results.
Keep system prompts and user prompts separate in LLM-related code.
System prompt should define the LLM's role and task specifications.
User prompt should contain the actual data and context.
Always define a Zod schema for response validation in LLM-related functions.
Make Zod schemas as specific as possible to guide the LLM output.
Use descriptive scoped loggers for each LLM feature.
Log inputs and outputs with appropriate log levels in LLM-related functions.
Include relevant context in log messages for LLM-related code.
Implement early returns for invalid inputs in LLM-related functions.
Use proper error types and logging in LLM-related code.
Implement fallbacks for AI failures in LLM-related functions.
Add retry logic for transient failures using withRetry in LLM-related code.
Use XML-like tags to structure data in LLM prompts.
Remove excessive whitespace and truncate long inputs in LLM prompts.
Format data consistently across similar LLM-related functions.
Use TypeScript types for all parameters and return values in LLM-related code.
Define clear interfaces for complex input/output structures in LLM-related code.
Extract common patterns into utility functions in LLM-related code.
Document complex AI logic with clear comments in LLM-related code.Files:
apps/web/utils/ai/actions.tsapps/web/utils/ai/choose-rule/match-rules.ts**/*.test.{ts,js}
📄 CodeRabbit Inference Engine (.cursor/rules/security.mdc)
Include security tests in your test suites to verify authentication, authorization, and error handling.
Files:
apps/web/utils/scheduled-actions/executor.test.ts**/*.test.{ts,js,tsx,jsx}
📄 CodeRabbit Inference Engine (.cursor/rules/testing.mdc)
**/*.test.{ts,js,tsx,jsx}: Tests are colocated next to the tested file (e.g.,dir/format.tsanddir/format.test.ts)
Usevi.mock("server-only", () => ({}));to mock theserver-onlymodule in tests
Mock@/utils/prismain tests usingvi.mock("@/utils/prisma")and use the provided prisma mock
Mock external dependencies in tests
Clean up mocks between tests
Do not mock the LoggerFiles:
apps/web/utils/scheduled-actions/executor.test.ts**/*.{test,spec}.{js,jsx,ts,tsx}
📄 CodeRabbit Inference Engine (.cursor/rules/ultracite.mdc)
**/*.{test,spec}.{js,jsx,ts,tsx}: Don't use export or module.exports in test files.
Don't use focused tests.
Don't use disabled tests.
Make sure the assertion function, like expect, is placed inside an it() function call.
Don't nest describe() blocks too deeply in test files.
Don't use focused tests.
Don't use disabled tests.
Don't use export or module.exports in test files.Files:
apps/web/utils/scheduled-actions/executor.test.ts*{TASKS,ASSISTANT_CHAT,*.md}
📄 CodeRabbit Inference Engine (.cursor/rules/task-list.mdc)
*{TASKS,ASSISTANT_CHAT,*.md}: Create task lists in a markdown file in the project root, usingTASKS.mdor a descriptive name relevant to the feature (e.g.,ASSISTANT_CHAT.md), and include a clear title and description of the feature being implemented.
Structure the task list markdown file with sections: Completed Tasks, In Progress Tasks, Future Tasks, Implementation Plan, and Relevant Files.
Update the task list as you progress: mark tasks as completed by changing[ ]to[x], add new tasks as identified, and move tasks between sections as appropriate.
Keep the 'Relevant Files' section updated with file paths, brief descriptions of each file's purpose, and status indicators (e.g., ✅) for completed components.
Add implementation details to the task list markdown file, including architecture decisions, data flow descriptions, technical components needed, and environment configuration.
When working with task lists, regularly update the task list file after implementing significant components, mark completed tasks with [x], add new tasks discovered during implementation, maintain the 'Relevant Files' section, and document implementation details.
When implementing tasks one by one, first check which task to implement next, and after implementing a task, update the file to reflect progress.Files:
README.md🧬 Code Graph Analysis (3)
apps/web/utils/ai/choose-rule/match-rules.ts (1)
apps/web/utils/thread.ts (1)
isReplyInThread(5-14)apps/web/utils/thread.ts (3)
apps/web/utils/types.ts (1)
ParsedMessage(85-85)apps/web/utils/gmail/message.ts (1)
isGmailReplyInThread(29-31)apps/web/utils/outlook/message.ts (1)
isOutlookReplyInThread(18-32)apps/web/utils/gmail/message.ts (3)
apps/web/utils/logger.ts (1)
createScopedLogger(17-65)apps/web/utils/types.ts (4)
ParsedMessage(85-85)GmailParsedMessage(77-79)MessageWithPayload(40-42)ThreadWithPayloadMessages(44-46)apps/web/utils/outlook/message.ts (1)
parseMessage(346-373)⏰ 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). (2)
- GitHub Check: Static Code Analysis Js
- GitHub Check: Jit Security
🔇 Additional comments (43)
apps/web/app/api/user/no-reply/route.ts (2)
4-4: Import path update is correct but consider side-effects on typings
parseMessagenow returns a discriminated-union withmetadata.provider === "gmail".
Nothing to change here – all downstream code in this file assumes Gmail anyway.
42-45: Ensurethreads.getreturns full message payloadsIn
apps/web/utils/gmail/thread.ts(around line 15), add theformat: "full"parameter to the existingthreads.getcall so that all headers and body parts are included for downstream parsing:- const thread = await gmail.users.threads.get({ userId: "me", id: threadId }); + const thread = await gmail.users.threads.get({ + userId: "me", + id: threadId, + format: "full", + });This change guarantees that
thread.messagescontains a complete payload suitable forparseMessage(including inno-reply/route.ts).apps/web/utils/outlook/draft.ts (1)
10-14: Follow-up: fix provider metadata after correcting the importAfter switching to the Outlook parser verify that returned messages have:
metadata: { provider: "outlook", /* ... */ }and adjust any downstream type-guards/tests.
apps/web/utils/gmail/thread.ts (2)
8-8: Import path update LGTMThe Gmail-specific parser is now used consistently across the file.
168-173: No parsing issue:users.threads.getdefaults to"full"The Gmail API returns the full payload when you omit the
formatparameter, so yourgetThreadcall already includes complete message bodies.parseMessagewill receive the expected data—no changes needed.Likely an incorrect or invalid review comment.
apps/web/app/(app)/[emailAccountId]/simple/page.tsx (1)
9-9: Parser import switched – no further action neededMatches the Gmail-only context of this page.
apps/web/utils/gmail/draft.ts (1)
3-3: Import path update confirmedGmail drafts now use the Gmail parser – consistent with the refactor.
apps/web/utils/gmail/mail.ts (1)
8-8: LGTM! Good architectural refactor.The import change properly isolates Gmail-specific parsing logic into a dedicated module, improving modularity and following the coding guidelines for keeping provider-specific implementation details in appropriate utils subfolders.
apps/web/app/api/user/group/[groupId]/messages/controller.ts (1)
7-7: LGTM! Consistent with architectural refactor.The import update aligns with the broader refactor to centralize Gmail message parsing in provider-specific modules, maintaining functionality while improving code organization.
apps/web/app/api/google/webhook/process-history-item.ts (1)
4-4: LGTM! Thoughtful separation of provider-specific vs generic utilities.The selective refactoring appropriately moves Gmail-specific
parseMessageto the provider-specific module while keeping genericemailToContentin the shared mail utilities, demonstrating good architectural judgment.apps/web/utils/ai/actions.ts (2)
142-145: Consistent metadata addition - verify provider assumption.The metadata fields are consistently added across action functions. Same verification needed for the hardcoded Gmail provider assumption.
206-209: Consistent implementation across action functions.The metadata additions maintain consistency with the other action functions in this file, supporting the new provider-aware message handling.
apps/web/utils/actions/ai-rule.ts (1)
152-155: LGTM! Appropriate test message structure update.The addition of
labelIdsandmetadata.providerfields ensures the test message conforms to the newParsedMessagediscriminated union type. Hardcoding Gmail as the provider is acceptable in this test context.apps/web/utils/ai/choose-rule/match-rules.ts (1)
235-235: LGTM! Clean API simplification.The change from passing three separate parameters to a single
messageobject improves the API design and aligns with the provider-aware refactoring. TheisReplyInThreadfunction can now handle provider-specific logic internally based onmessage.metadata.provider.apps/web/app/api/clean/route.ts (1)
117-119: LGTM! Simplified attachment detection.The change from inspecting payload parts to directly checking the
attachmentsproperty simplifies the logic and aligns with the standardized message structure. This approach is more direct and consistent across email providers.README.md (2)
27-27: LGTM! Added Microsoft OAuth environment variables to deployment.Adding the Microsoft client credentials to the Vercel deployment button ensures users will be prompted to configure these essential environment variables for Outlook integration.
184-186: LGTM! Improved Azure setup instructions clarity.Reordering the redirect URI setup to occur after clicking "Register" clarifies the correct sequence of operations for Azure app registration, making the setup process easier to follow.
apps/web/utils/email/provider.ts (4)
4-4: LGTM! Moved to provider-specific import.Moving the
parseMessageimport from the generic mail utility to the Gmail-specific module improves code organization and supports the provider-aware architecture refactoring.
1373-1373: LGTM! Added conversationIndex to Outlook message selection.Including
conversationIndexin the select clause ensures this important Outlook-specific metadata is captured for proper thread handling and message processing.
1410-1410: LGTM! Added optional conversationIndex to type definition.Making
conversationIndexoptional in the type definition correctly reflects the API response structure where this field may not always be present.
1477-1480: LGTM! Implemented provider metadata for discriminated union.Adding the
metadataobject withprovider: "outlook"andconversationIndexcorrectly implements the discriminated union pattern forParsedMessage, enabling provider-aware processing throughout the codebase while preserving Outlook-specific information.apps/web/utils/scheduled-actions/executor.test.ts (3)
16-34: LGTM! Consolidated mocks with email provider abstraction.Replacing multiple Gmail-specific mocks with a single email provider mock improves test maintainability and aligns with the production code's use of the email provider abstraction. The mock provides all necessary message fields for comprehensive testing.
128-137: LGTM! Updated test to use email provider dependency injection.The test correctly creates an email provider instance and passes it to
executeScheduledAction, following the new dependency injection pattern and making the test more realistic and maintainable.
203-212: LGTM! Consistent email provider usage across all test cases.All test cases now consistently use the email provider pattern, ensuring uniform test setup and making the test suite more maintainable. The dependency injection approach better reflects the production code structure.
Also applies to: 234-240
apps/web/utils/thread.ts (1)
5-14: LGTM! Clean refactoring with improved type safety.The function signature change from separate parameters to a single
ParsedMessageobject is a significant improvement. The discriminated union approach with the switch statement onmessage.metadata.providerprovides type safety and clear separation of provider-specific logic.apps/web/utils/mail.ts (2)
4-4: Import update aligns with discriminated union refactoring.The updated import to use
ParsedMessagefrom@/utils/typesis consistent with the new discriminated union structure and the removal of Gmail-specific parsing logic from this file.
73-73: Generic email processing function updated for new type structure.The
emailToContentfunction correctly uses thePickutility type to extract only the necessary fields fromParsedMessage, making it provider-agnostic and working with both Gmail and Outlook messages.apps/web/app/api/outlook/webhook/process-history-item.ts (3)
119-126: Consistent metadata structure for assistant email processing.The addition of
labelIds,internalDate, andmetadatawithprovider: "outlook"correctly aligns with the new discriminated unionParsedMessagetype. MovingconversationIndexinto the metadata object is the right approach for Outlook-specific data.
242-249: Consistent metadata structure for automation rules.Same pattern applied consistently for rule execution, ensuring all Outlook message objects follow the new discriminated union structure.
307-314: Consistent metadata structure for outbound message handling.The pattern is applied consistently across all message constructions in this file, ensuring proper type compliance with the new
ParsedMessagediscriminated union.apps/web/utils/gmail/message.ts (4)
22-26: Well-implemented type guard for Gmail messages.The
isGmailMessagetype guard correctly uses the discriminated union'smetadata.providerfield to narrow the type toGmailParsedMessage. This enables type-safe operations on Gmail-specific properties.
28-31: Correct implementation of Gmail reply detection.The logic
message.id !== message.threadIdis correct for Gmail, where the first message ID in a thread equals the thread ID. The comment on line 28 clearly explains this Gmail-specific behavior.
33-45: Clean Gmail message parsing with proper metadata.The function correctly:
- Uses the
gmail-api-parse-messagelibrary for parsing- Adds explicit
subjectanddatefields from headers- Sets
metadata.providerto"gmail"for discriminated union compliance- Maintains the return type constraint with subject and date fields
47-78: Robust message filtering implementation.The
parseMessagesfunction provides flexible filtering options:
- Filters out messages from ignored senders using
isIgnoredSender- Filters out draft messages using
GmailLabel.DRAFT- Maintains clean separation of concerns with optional filtering
The implementation correctly handles the optional filtering parameters and maintains type safety.
apps/web/utils/types.ts (2)
48-85: Excellent discriminated union design for provider separation.The refactoring from a single
ParsedMessageinterface to a discriminated union is well-executed:
BaseParsedMessagecontains common fields across providersGmailMetadataandOutlookMetadataprovide provider-specific typing- The discriminated union enables type-safe handling with TypeScript's type narrowing
- Moving
conversationIndexto Outlook-only metadata correctly reflects provider-specific dataThis design will prevent runtime errors and improve developer experience with proper type checking.
65-65: Please manually verify that every message parser setslabelIds
I wasn’t able to locate the implementations ofparseGmailMessage,parseOutlookMessage, or any genericparseMessagein the utility modules. SincelabelIdsis now required onBaseParsedMessage, double-check that:
parseGmailMessagealways includes alabelIds: string[]fieldparseOutlookMessagealways includes alabelIds: string[]field- Any other custom message-parsing functions populate
labelIds(use an empty array if none)This manual pass will ensure no runtime errors crop up due to missing labels.
apps/web/utils/outlook/message.ts (6)
2-2: LGTM: Import addition supports discriminated union pattern.The addition of
OutlookParsedMessagetype import aligns with the refactor to use discriminated unions for provider-specific message types.
12-16: LGTM: Well-implemented type guard function.The type guard correctly implements TypeScript's type predicate pattern to safely narrow
ParsedMessagetoOutlookParsedMessagebased on the provider metadata.
18-32: LGTM: Improved type safety in reply detection.The refactor to accept a full
ParsedMessageand use the type guard provides better type safety. The early return for non-Outlook messages is appropriate, and the conversationIndex access through metadata is correct.
292-292: LGTM: Centralized parsing improves maintainability.Using the shared
parseMessagefunction eliminates code duplication and centralizes the message parsing logic.
310-310: LGTM: Consistent use of centralized parsing.Consistent with the
convertMessagesrefactor, usingparseMessagemaintains code consistency and reduces duplication.
346-373: LGTM: Well-structured parseMessage function supports discriminated union.The function correctly implements the new metadata structure with provider identification and centralizes Outlook message parsing. The explicit
textHtmlfield setting and export for reusability are good improvements.apps/web/app/api/google/threads/controller.ts (1)
1-1: Alias mapping validated
The import@/utils/gmail/messageis covered by the"@/*": ["./*"]entry in apps/web/tsconfig.json (baseUrl “.”), and the file exists at apps/web/utils/gmail/message.ts. No further action required.File: apps/web/app/api/google/threads/controller.ts
Lines: 1-1import { parseMessages } from "@/utils/gmail/message";
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
apps/web/utils/gmail/message.ts (1)
40-71: Consider explicit return type and optimized filtering logic.The function works correctly but could benefit from improvements:
- Add explicit return type for better type safety
- Optimize filtering logic to avoid double iteration
Apply this diff to improve the implementation:
export function parseMessages( thread: ThreadWithPayloadMessages, { withoutIgnoredSenders, withoutDrafts, }: { withoutIgnoredSenders?: boolean; withoutDrafts?: boolean; } = {}, +): ParsedMessage[] { const messages = thread.messages?.map((message: MessageWithPayload) => { return parseMessage(message); }) || []; - if (withoutIgnoredSenders || withoutDrafts) { - const filteredMessages = messages.filter((message) => { - if ( - withoutIgnoredSenders && - message.headers && - isIgnoredSender(message.headers.from) - ) - return false; - if (withoutDrafts && message.labelIds?.includes(GmailLabel.DRAFT)) - return false; - return true; - }); - return filteredMessages; - } - - return messages; + return messages.filter((message) => { + if ( + withoutIgnoredSenders && + message.headers && + isIgnoredSender(message.headers.from) + ) + return false; + if (withoutDrafts && message.labelIds?.includes(GmailLabel.DRAFT)) + return false; + return true; + });
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (10)
apps/web/app/api/outlook/webhook/process-history-item.ts(3 hunks)apps/web/utils/actions/ai-rule.ts(2 hunks)apps/web/utils/ai/actions.ts(3 hunks)apps/web/utils/email/provider.ts(4 hunks)apps/web/utils/gmail/message.ts(2 hunks)apps/web/utils/outlook/mail.ts(1 hunks)apps/web/utils/outlook/message.ts(5 hunks)apps/web/utils/outlook/thread.ts(1 hunks)apps/web/utils/thread.ts(1 hunks)apps/web/utils/types.ts(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (9)
- apps/web/utils/outlook/thread.ts
- apps/web/utils/outlook/mail.ts
- apps/web/utils/ai/actions.ts
- apps/web/utils/actions/ai-rule.ts
- apps/web/utils/types.ts
- apps/web/utils/email/provider.ts
- apps/web/app/api/outlook/webhook/process-history-item.ts
- apps/web/utils/thread.ts
- apps/web/utils/outlook/message.ts
🧰 Additional context used
📓 Path-based instructions (9)
apps/web/**/*.{ts,tsx}
📄 CodeRabbit Inference Engine (apps/web/CLAUDE.md)
apps/web/**/*.{ts,tsx}: Use TypeScript with strict null checks
Path aliases: Use@/for imports from project root
Use proper error handling with try/catch blocks
Format code with Prettier
Leverage TypeScript inference for better DX
Files:
apps/web/utils/gmail/message.ts
!{.cursor/rules/*.mdc}
📄 CodeRabbit Inference Engine (.cursor/rules/cursor-rules.mdc)
Never place rule files in the project root, in subdirectories outside .cursor/rules, or in any other location
Files:
apps/web/utils/gmail/message.ts
**/*.ts
📄 CodeRabbit Inference Engine (.cursor/rules/form-handling.mdc)
**/*.ts: The same validation should be done in the server action too
Define validation schemas using Zod
Files:
apps/web/utils/gmail/message.ts
apps/web/utils/gmail/**/*.ts
📄 CodeRabbit Inference Engine (.cursor/rules/gmail-api.mdc)
Keep provider-specific implementation details isolated in the appropriate utils subfolder (e.g., 'apps/web/utils/gmail/')
Files:
apps/web/utils/gmail/message.ts
**/*.{ts,tsx}
📄 CodeRabbit Inference Engine (.cursor/rules/logging.mdc)
**/*.{ts,tsx}: UsecreateScopedLoggerfor logging in backend TypeScript files
Typically add the logger initialization at the top of the file when usingcreateScopedLogger
Only use.with()on a logger instance within a specific function, not for a global loggerImport Prisma in the project using
import prisma from "@/utils/prisma";
**/*.{ts,tsx}: Don't use TypeScript enums.
Don't use TypeScript const enum.
Don't use the TypeScript directive @ts-ignore.
Don't use primitive type aliases or misleading types.
Don't use empty type parameters in type aliases and interfaces.
Don't use any or unknown as type constraints.
Don't use implicit any type on variable declarations.
Don't let variables evolve into any type through reassignments.
Don't use non-null assertions with the ! postfix operator.
Don't misuse the non-null assertion operator (!) in TypeScript files.
Don't use user-defined types.
Use as const instead of literal types and type annotations.
Use export type for types.
Use import type for types.
Don't declare empty interfaces.
Don't merge interfaces and classes unsafely.
Don't use overload signatures that aren't next to each other.
Use the namespace keyword instead of the module keyword to declare TypeScript namespaces.
Don't use TypeScript namespaces.
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 parameter properties in class constructors.
Use either T[] or Array consistently.
Initialize each enum member value explicitly.
Make sure all enum members are literal values.
Files:
apps/web/utils/gmail/message.ts
apps/web/utils/**
📄 CodeRabbit Inference Engine (.cursor/rules/project-structure.mdc)
Create utility functions in
utils/folder for reusable logic
Files:
apps/web/utils/gmail/message.ts
apps/web/utils/**/*.ts
📄 CodeRabbit Inference Engine (.cursor/rules/project-structure.mdc)
apps/web/utils/**/*.ts: Use lodash utilities for common operations (arrays, objects, strings)
Import specific lodash functions to minimize bundle size
Files:
apps/web/utils/gmail/message.ts
**/*.{js,jsx,ts,tsx}
📄 CodeRabbit Inference Engine (.cursor/rules/ultracite.mdc)
**/*.{js,jsx,ts,tsx}: Don't useelements in Next.js projects.
Don't use elements in Next.js projects.
Don't use namespace imports.
Don't access namespace imports dynamically.
Don't use global eval().
Don't use console.
Don't use debugger.
Don't use var.
Don't use with statements in non-strict contexts.
Don't use the arguments object.
Don't use consecutive spaces in regular expression literals.
Don't use the comma operator.
Don't use unnecessary boolean casts.
Don't use unnecessary callbacks with flatMap.
Use for...of statements instead of Array.forEach.
Don't create classes that only have static members (like a static namespace).
Don't use this and super in static contexts.
Don't use unnecessary catch clauses.
Don't use unnecessary constructors.
Don't use unnecessary continue statements.
Don't export empty modules that don't change anything.
Don't use unnecessary escape sequences in regular expression literals.
Don't use unnecessary labels.
Don't use unnecessary nested block statements.
Don't rename imports, exports, and destructured assignments to the same name.
Don't use unnecessary string or template literal concatenation.
Don't use String.raw in template literals when there are no escape sequences.
Don't use useless case statements in switch statements.
Don't use ternary operators when simpler alternatives exist.
Don't use useless this aliasing.
Don't initialize variables to undefined.
Don't use the void operators (they're not familiar).
Use arrow functions instead of function expressions.
Use Date.now() to get milliseconds since the Unix Epoch.
Use .flatMap() instead of map().flat() when possible.
Use literal property access instead of computed property access.
Don't use parseInt() or Number.parseInt() when binary, octal, or hexadecimal literals work.
Use concise optional chaining instead of chained logical expressions.
Use regular expression literals instead of the RegExp constructor when possible.
Don't use number literal object member names th...
Files:
apps/web/utils/gmail/message.ts
!pages/_document.{js,jsx,ts,tsx}
📄 CodeRabbit Inference Engine (.cursor/rules/ultracite.mdc)
!pages/_document.{js,jsx,ts,tsx}: Don't import next/document outside of pages/_document.jsx in Next.js projects.
Don't import next/document outside of pages/_document.jsx in Next.js projects.
Files:
apps/web/utils/gmail/message.ts
⏰ 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). (2)
- GitHub Check: Static Code Analysis Js
- GitHub Check: Jit Security
🔇 Additional comments (5)
apps/web/utils/gmail/message.ts (5)
1-18: Import changes look good and support the architectural refactoring.The new imports properly support the Gmail-specific functionality and follow established patterns with appropriate type imports.
22-24: Simple and correct Gmail thread reply detection.The logic correctly identifies replies by comparing message ID with thread ID, which aligns with Gmail's threading model.
26-38: Good implementation of provider-specific parsing with required metadata.The function properly extends the parsed message with Gmail-specific metadata and handles missing headers gracefully.
73-375: Existing functions properly adapted to use the new parsing logic.The functions maintain their original functionality while correctly using the new local
parseMessagefunction. Error handling, logging, and type safety are well implemented throughout.
1-375: Excellent architectural refactoring that successfully achieves PR objectives.This file successfully:
- ✅ Consolidates Gmail-specific message parsing logic
- ✅ Introduces provider metadata for discriminated union support
- ✅ Maintains proper separation of concerns by provider
- ✅ Follows TypeScript best practices and coding guidelines
- ✅ Preserves existing functionality while improving type safety
The migration from shared utilities to provider-specific modules is well-executed and supports the broader codebase refactoring goals.
| message.threadId, | ||
| message.conversationIndex, | ||
| ); | ||
| const isThread = isReplyInThread(message); |
There was a problem hiding this comment.
Passing the entire message to call a function based on the provider.
| @@ -115,7 +115,7 @@ async function cleanThread({ | |||
| } | |||
|
|
|||
| function hasAttachments(message: ParsedMessage) { | |||
There was a problem hiding this comment.
Changed to be provider agnostic
| import { getMessage, getMessages } from "@/utils/gmail/message"; | ||
| import { findMatchingGroupItem } from "@/utils/group/find-matching-group"; | ||
| import { parseMessage } from "@/utils/mail"; | ||
| import { parseMessage } from "@/utils/gmail/message"; |
There was a problem hiding this comment.
This parsing shouldn't be from Gmail.
The parseMessage should be from the actual email provider.
Unless we want the parseMessage to be generic.
The current implementation expects the parseMessage input to match the Gmail schema, so runtime errors could occur if we use it with the Outlook schema.
| return !!(message.id && message.id !== message.threadId); | ||
| } | ||
|
|
||
| export function parseMessage( |
There was a problem hiding this comment.
Moved the parseMessage from utils/mail.ts to here because its input ´MessageWithPayload` is a Gmail schema message.
| } from "@/app/(app)/[emailAccountId]/simple/categories"; | ||
| import { PageHeading } from "@/components/Typography"; | ||
| import { parseMessage } from "@/utils/mail"; | ||
| import { parseMessage } from "@/utils/gmail/message"; |
There was a problem hiding this comment.
is this right? (not critical either way as we don't need to support simple email mode. i should probs delete it from the project at this point tbh)
There was a problem hiding this comment.
Yes. This was highlighted because I moved the parseMessage to Gmail.
Other places are using this parser, which should be worked on.
edulelis
changed the title
edulelis
changed the title
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
apps/web/utils/outlook/message.ts (1)
333-333: Consider differentiating HTML and plain text content.Both
textPlainandtextHtmlare set to the samemessage.body?.contentvalue. If Outlook provides different formats, consider handling them separately to provide more accurate content representation.- textHtml: message.body?.content || "", + textHtml: message.body?.contentType === 'html' ? message.body?.content || "" : "",Note: This assumes the Outlook API provides
contentTypeinformation. Verify the actual API response structure.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (13)
apps/web/app/api/outlook/webhook/process-history-item.ts(3 hunks)apps/web/utils/actions/ai-rule.ts(1 hunks)apps/web/utils/ai/actions.ts(3 hunks)apps/web/utils/ai/choose-rule/match-rules.test.ts(25 hunks)apps/web/utils/ai/choose-rule/match-rules.ts(1 hunks)apps/web/utils/email/provider.ts(7 hunks)apps/web/utils/gmail/message.ts(2 hunks)apps/web/utils/outlook/draft.ts(2 hunks)apps/web/utils/outlook/mail.ts(2 hunks)apps/web/utils/outlook/message.ts(4 hunks)apps/web/utils/outlook/thread.ts(1 hunks)apps/web/utils/thread.ts(0 hunks)apps/web/utils/types.ts(2 hunks)
💤 Files with no reviewable changes (1)
- apps/web/utils/thread.ts
✅ Files skipped from review due to trivial changes (3)
- apps/web/utils/outlook/draft.ts
- apps/web/utils/ai/choose-rule/match-rules.ts
- apps/web/utils/ai/choose-rule/match-rules.test.ts
🚧 Files skipped from review as they are similar to previous changes (8)
- apps/web/utils/actions/ai-rule.ts
- apps/web/utils/outlook/mail.ts
- apps/web/utils/ai/actions.ts
- apps/web/utils/types.ts
- apps/web/utils/outlook/thread.ts
- apps/web/app/api/outlook/webhook/process-history-item.ts
- apps/web/utils/gmail/message.ts
- apps/web/utils/email/provider.ts
🧰 Additional context used
📓 Path-based instructions (8)
apps/web/**/*.{ts,tsx}
📄 CodeRabbit Inference Engine (apps/web/CLAUDE.md)
apps/web/**/*.{ts,tsx}: Use TypeScript with strict null checks
Path aliases: Use@/for imports from project root
Use proper error handling with try/catch blocks
Format code with Prettier
Leverage TypeScript inference for better DX
Files:
apps/web/utils/outlook/message.ts
!{.cursor/rules/*.mdc}
📄 CodeRabbit Inference Engine (.cursor/rules/cursor-rules.mdc)
Never place rule files in the project root, in subdirectories outside .cursor/rules, or in any other location
Files:
apps/web/utils/outlook/message.ts
**/*.ts
📄 CodeRabbit Inference Engine (.cursor/rules/form-handling.mdc)
**/*.ts: The same validation should be done in the server action too
Define validation schemas using Zod
Files:
apps/web/utils/outlook/message.ts
**/*.{ts,tsx}
📄 CodeRabbit Inference Engine (.cursor/rules/logging.mdc)
**/*.{ts,tsx}: UsecreateScopedLoggerfor logging in backend TypeScript files
Typically add the logger initialization at the top of the file when usingcreateScopedLogger
Only use.with()on a logger instance within a specific function, not for a global loggerImport Prisma in the project using
import prisma from "@/utils/prisma";
**/*.{ts,tsx}: Don't use TypeScript enums.
Don't use TypeScript const enum.
Don't use the TypeScript directive @ts-ignore.
Don't use primitive type aliases or misleading types.
Don't use empty type parameters in type aliases and interfaces.
Don't use any or unknown as type constraints.
Don't use implicit any type on variable declarations.
Don't let variables evolve into any type through reassignments.
Don't use non-null assertions with the ! postfix operator.
Don't misuse the non-null assertion operator (!) in TypeScript files.
Don't use user-defined types.
Use as const instead of literal types and type annotations.
Use export type for types.
Use import type for types.
Don't declare empty interfaces.
Don't merge interfaces and classes unsafely.
Don't use overload signatures that aren't next to each other.
Use the namespace keyword instead of the module keyword to declare TypeScript namespaces.
Don't use TypeScript namespaces.
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 parameter properties in class constructors.
Use either T[] or Array consistently.
Initialize each enum member value explicitly.
Make sure all enum members are literal values.
Files:
apps/web/utils/outlook/message.ts
apps/web/utils/**
📄 CodeRabbit Inference Engine (.cursor/rules/project-structure.mdc)
Create utility functions in
utils/folder for reusable logic
Files:
apps/web/utils/outlook/message.ts
apps/web/utils/**/*.ts
📄 CodeRabbit Inference Engine (.cursor/rules/project-structure.mdc)
apps/web/utils/**/*.ts: Use lodash utilities for common operations (arrays, objects, strings)
Import specific lodash functions to minimize bundle size
Files:
apps/web/utils/outlook/message.ts
**/*.{js,jsx,ts,tsx}
📄 CodeRabbit Inference Engine (.cursor/rules/ultracite.mdc)
**/*.{js,jsx,ts,tsx}: Don't useelements in Next.js projects.
Don't use elements in Next.js projects.
Don't use namespace imports.
Don't access namespace imports dynamically.
Don't use global eval().
Don't use console.
Don't use debugger.
Don't use var.
Don't use with statements in non-strict contexts.
Don't use the arguments object.
Don't use consecutive spaces in regular expression literals.
Don't use the comma operator.
Don't use unnecessary boolean casts.
Don't use unnecessary callbacks with flatMap.
Use for...of statements instead of Array.forEach.
Don't create classes that only have static members (like a static namespace).
Don't use this and super in static contexts.
Don't use unnecessary catch clauses.
Don't use unnecessary constructors.
Don't use unnecessary continue statements.
Don't export empty modules that don't change anything.
Don't use unnecessary escape sequences in regular expression literals.
Don't use unnecessary labels.
Don't use unnecessary nested block statements.
Don't rename imports, exports, and destructured assignments to the same name.
Don't use unnecessary string or template literal concatenation.
Don't use String.raw in template literals when there are no escape sequences.
Don't use useless case statements in switch statements.
Don't use ternary operators when simpler alternatives exist.
Don't use useless this aliasing.
Don't initialize variables to undefined.
Don't use the void operators (they're not familiar).
Use arrow functions instead of function expressions.
Use Date.now() to get milliseconds since the Unix Epoch.
Use .flatMap() instead of map().flat() when possible.
Use literal property access instead of computed property access.
Don't use parseInt() or Number.parseInt() when binary, octal, or hexadecimal literals work.
Use concise optional chaining instead of chained logical expressions.
Use regular expression literals instead of the RegExp constructor when possible.
Don't use number literal object member names th...
Files:
apps/web/utils/outlook/message.ts
!pages/_document.{js,jsx,ts,tsx}
📄 CodeRabbit Inference Engine (.cursor/rules/ultracite.mdc)
!pages/_document.{js,jsx,ts,tsx}: Don't import next/document outside of pages/_document.jsx in Next.js projects.
Don't import next/document outside of pages/_document.jsx in Next.js projects.
Files:
apps/web/utils/outlook/message.ts
🧠 Learnings (2)
📓 Common learnings
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-07-18T15:05:34.899Z
Learning: Applies to apps/web/utils/gmail/**/*.ts : Keep provider-specific implementation details isolated in the appropriate utils subfolder (e.g., 'apps/web/utils/gmail/')
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/index.mdc:0-0
Timestamp: 2025-07-18T15:05:56.644Z
Learning: Guidelines for working with Gmail API
apps/web/utils/outlook/message.ts (1)
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-07-18T15:05:34.899Z
Learning: Applies to apps/web/utils/gmail/**/*.ts : Keep provider-specific implementation details isolated in the appropriate utils subfolder (e.g., 'apps/web/utils/gmail/')
🧬 Code Graph Analysis (1)
apps/web/utils/outlook/message.ts (1)
apps/web/utils/types.ts (1)
ParsedMessage(47-62)
⏰ 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). (2)
- GitHub Check: Static Code Analysis Js
- GitHub Check: Jit Security
🔇 Additional comments (5)
apps/web/utils/outlook/message.ts (5)
270-270: LGTM: Function call updated to use renamed function.The call to
convertMessagecorrectly reflects the function rename fromparseOutlookMessageand maintains the same functionality.
288-288: LGTM: Function call updated consistently.The call to
convertMessageingetMessageis consistent with the refactoring and maintains the same behavior.
324-327: LGTM: Function export and signature are appropriate.The function is now properly exported to support centralized message conversion logic, and the default parameter for
folderIdsprovides good fallback behavior.
343-343: LGTM:internalDatefield addition aligns with interface.The addition of
internalDateusingreceivedDateTimeis consistent with theParsedMessageinterface shown in the relevant code snippets.
346-346: LGTM:conversationIndexfield addition supports thread detection.The addition of
conversationIndexaligns with the PR objectives for Outlook refactor and the AI summary mentioning its use for thread reply detection. The field is correctly typed as optional in theParsedMessageinterface.
| await unwatchOutlook(this.client.getClient(), subscriptionId); | ||
| } | ||
|
|
||
| isReplyInThread(message: ParsedMessage): boolean { |
There was a problem hiding this comment.
Moved isReplyInThread to the provider
| import { getAccessTokenFromClient } from "@/utils/gmail/client"; | ||
| import { GmailLabel } from "@/utils/gmail/label"; | ||
| import { isIgnoredSender } from "@/utils/filter-ignored-senders"; | ||
| import parse from "gmail-api-parse-message"; |
There was a problem hiding this comment.
This parser is being moved from utils/mail
| thread: { | ||
| ...thread, | ||
| messages: thread.messages?.map((message) => { | ||
| // TODO need to fetch full message with `getMessage()` here? |
There was a problem hiding this comment.
getThread uses getMessages, which will parse the message
elie222
changed the title
2 participants
Summary by CodeRabbit
New Features
conversationIndexproperty in Outlook messages.Refactor
Bug Fixes
conversationIndexproperty in Outlook message processing.Documentation
Tests
Chores