assistant: fix CC/BCC recipients not being added to draft replies#1156
assistant: fix CC/BCC recipients not being added to draft replies#1156
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. 📝 WalkthroughWalkthroughAdds optional cc and bcc support across the email-drafting flow: expands provider/type signatures, forwards cc/bcc from the AI draft action, merges/deduplicates reply-all CCs, and includes BCC handling in Gmail and Outlook draft builders and tests. (47 words) Changes
Sequence DiagramsequenceDiagram
participant AI as AI Action Handler
participant Client as Email Provider Layer
participant Gmail as Gmail Draft Builder
participant Outlook as Outlook Draft Builder
participant Util as Reply-All Utility
AI->>Client: draftEmail(email, {to, subject, content, cc, bcc})
Client->>Util: buildReplyAllRecipients(email)
Util-->>Client: existingReplyAllCCs
Client->>Gmail: draftEmail(email, args) activate
Note right of Gmail: merge reply-all CCs\nwith args.cc (dedupe)
Gmail->>Gmail: build ccList & bccList
Gmail-->>Client: drafted message (raw with cc/bcc) deactivate
Client->>Outlook: draftEmail(email, args) activate
Note right of Outlook: merge reply-all CCs\nwith args.cc (dedupe) and parse bcc
Outlook->>Outlook: build ccRecipients & bccRecipients
Outlook-->>Client: patched draft (with cc/bcc) deactivate
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ 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 |
Fix draft replies by adding CC/BCC handling across
|
![macroscopeapp[bot]](https://avatars.githubusercontent.com/in/900172?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
apps/web/utils/gmail/mail.ts (1)
272-281: Consider normalizing email addresses when checking for CC duplicates.The current duplicate detection uses
includes()which performs case-sensitive string matching. This could allow duplicate recipients with different formatting:
user@example.comvsUser@example.com(different casing)John <user@example.com>vsuser@example.com(with/without display name)💡 Suggested improvement with email normalization
// Merge CC from reply-all with CC from args const ccList = [...recipients.cc]; if (args.cc) { const manualCc = args.cc.split(",").map((s) => s.trim()); + // Normalize existing CCs for comparison + const normalizedExisting = ccList.map(addr => + extractEmailAddress(addr).toLowerCase() + ); for (const email of manualCc) { - if (!ccList.includes(email)) { + const normalizedEmail = extractEmailAddress(email).toLowerCase(); + if (!normalizedExisting.includes(normalizedEmail)) { ccList.push(email); + normalizedExisting.push(normalizedEmail); } } }Note: You'll need to import
extractEmailAddressfrom@/utils/emailif this approach is adopted.apps/web/utils/outlook/mail.ts (1)
218-235: Consider normalizing email addresses when checking for CC duplicates.Similar to the Gmail implementation, the duplicate detection uses
includes()which performs case-sensitive string matching. This could result in duplicate recipients with different casing or formatting.For consistency across providers and to prevent duplicate recipients, consider using the same email normalization approach as suggested for the Gmail implementation (extracting and lowercasing email addresses for comparison).
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
apps/web/utils/ai/actions.tsapps/web/utils/email/google.tsapps/web/utils/email/microsoft.tsapps/web/utils/email/types.tsapps/web/utils/gmail/mail.tsapps/web/utils/outlook/mail.ts
🧰 Additional context used
📓 Path-based instructions (16)
**/*.{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/email/types.tsapps/web/utils/email/google.tsapps/web/utils/outlook/mail.tsapps/web/utils/email/microsoft.tsapps/web/utils/ai/actions.tsapps/web/utils/gmail/mail.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/email/types.tsapps/web/utils/email/google.tsapps/web/utils/outlook/mail.tsapps/web/utils/email/microsoft.tsapps/web/utils/ai/actions.tsapps/web/utils/gmail/mail.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
Files:
apps/web/utils/email/types.tsapps/web/utils/email/google.tsapps/web/utils/outlook/mail.tsapps/web/utils/email/microsoft.tsapps/web/utils/ai/actions.tsapps/web/utils/gmail/mail.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/email/types.tsapps/web/utils/email/google.tsapps/web/utils/outlook/mail.tsapps/web/utils/email/microsoft.tsapps/web/utils/ai/actions.tsapps/web/utils/gmail/mail.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/email/types.tsapps/web/utils/email/google.tsapps/web/utils/outlook/mail.tsapps/web/utils/email/microsoft.tsapps/web/utils/ai/actions.tsapps/web/utils/gmail/mail.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/email/types.tsapps/web/utils/email/google.tsapps/web/utils/outlook/mail.tsapps/web/utils/email/microsoft.tsapps/web/utils/ai/actions.tsapps/web/utils/gmail/mail.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/email/types.tsapps/web/utils/email/google.tsapps/web/utils/outlook/mail.tsapps/web/utils/email/microsoft.tsapps/web/utils/ai/actions.tsapps/web/utils/gmail/mail.ts
!(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/utils/email/types.tsapps/web/utils/email/google.tsapps/web/utils/outlook/mail.tsapps/web/utils/email/microsoft.tsapps/web/utils/ai/actions.tsapps/web/utils/gmail/mail.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')
Files:
apps/web/utils/email/types.tsapps/web/utils/email/google.tsapps/web/utils/outlook/mail.tsapps/web/utils/email/microsoft.tsapps/web/utils/ai/actions.tsapps/web/utils/gmail/mail.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/email/types.tsapps/web/utils/email/google.tsapps/web/utils/outlook/mail.tsapps/web/utils/email/microsoft.tsapps/web/utils/ai/actions.tsapps/web/utils/gmail/mail.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
Prefer self-documenting code over comments; use descriptive variable and function names instead of explaining intent with comments
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/email/types.tsapps/web/utils/email/google.tsapps/web/utils/outlook/mail.tsapps/web/utils/email/microsoft.tsapps/web/utils/ai/actions.tsapps/web/utils/gmail/mail.ts
apps/web/**/*.{ts,tsx,js,jsx,json,css}
📄 CodeRabbit inference engine (apps/web/CLAUDE.md)
Format code with Prettier
Files:
apps/web/utils/email/types.tsapps/web/utils/email/google.tsapps/web/utils/outlook/mail.tsapps/web/utils/email/microsoft.tsapps/web/utils/ai/actions.tsapps/web/utils/gmail/mail.ts
apps/web/**/*.{example,ts,json}
📄 CodeRabbit inference engine (apps/web/CLAUDE.md)
Add environment variables to
.env.example,env.ts, andturbo.json
Files:
apps/web/utils/email/types.tsapps/web/utils/email/google.tsapps/web/utils/outlook/mail.tsapps/web/utils/email/microsoft.tsapps/web/utils/ai/actions.tsapps/web/utils/gmail/mail.ts
apps/web/{utils/ai,utils/llms,__tests__}/**/*.ts
📄 CodeRabbit inference engine (.cursor/rules/llm.mdc)
LLM-related code must be organized in specific directories:
apps/web/utils/ai/for main implementations,apps/web/utils/llms/for core utilities and configurations, andapps/web/__tests__/for LLM-specific tests
Files:
apps/web/utils/ai/actions.ts
apps/web/utils/ai/**/*.ts
📄 CodeRabbit inference engine (.cursor/rules/llm.mdc)
apps/web/utils/ai/**/*.ts: LLM feature functions must import fromzodfor schema validation, usecreateScopedLoggerfrom@/utils/logger,chatCompletionObjectandcreateGenerateObjectfrom@/utils/llms, and importEmailAccountWithAItype from@/utils/llms/types
LLM feature functions must follow a standard structure: accept options withinputDataandemailAccountparameters, implement input validation with early returns, define separate system and user prompts, create a Zod schema for response validation, and usecreateGenerateObjectto execute the LLM call
System prompts must define the LLM's role and task specifications
User prompts must contain the actual data and context, and should be kept separate from system prompts
Always define a Zod schema for LLM response validation and make 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, and include relevant context in log messages
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 usingwithRetry
Use XML-like tags to structure data in prompts, remove excessive whitespace and truncate long inputs, and format data consistently across similar LLM functions
Use TypeScript types for all LLM function parameters and return values, and define clear interfaces for complex input/output structures
Keep related AI functions in the same file or directory, extract common patterns into utility functions, and document complex AI logic with clear comments
Files:
apps/web/utils/ai/actions.ts
apps/web/utils/gmail/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/gmail-api.mdc)
apps/web/utils/gmail/**/*.{ts,tsx}: Always use wrapper functions from @/utils/gmail/ for Gmail API operations instead of direct provider API calls
Keep Gmail provider-specific implementation details isolated within the apps/web/utils/gmail/ directory
Files:
apps/web/utils/gmail/mail.ts
🧠 Learnings (7)
📚 Learning: 2025-07-17T04:19:57.099Z
Learnt from: edulelis
Repo: elie222/inbox-zero PR: 576
File: packages/resend/emails/digest.tsx:78-83
Timestamp: 2025-07-17T04:19:57.099Z
Learning: In packages/resend/emails/digest.tsx, the DigestEmailProps type uses `[key: string]: DigestItem[] | undefined | string | Date | undefined` instead of intersection types like `& Record<string, DigestItem[] | undefined>` due to implementation constraints. This was the initial implementation approach and cannot be changed to more restrictive typing.
Applied to files:
apps/web/utils/email/types.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 thread operations from @/utils/gmail/thread.ts instead of direct API calls
Applied to files:
apps/web/utils/email/types.tsapps/web/utils/email/google.tsapps/web/utils/outlook/mail.tsapps/web/utils/ai/actions.tsapps/web/utils/gmail/mail.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/utils/email/types.tsapps/web/utils/email/google.tsapps/web/utils/gmail/mail.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/utils/email/google.tsapps/web/utils/outlook/mail.tsapps/web/utils/email/microsoft.tsapps/web/utils/ai/actions.tsapps/web/utils/gmail/mail.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/utils/email/google.tsapps/web/utils/gmail/mail.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} : Always use wrapper functions from @/utils/gmail/ for Gmail API operations instead of direct provider API calls
Applied to files:
apps/web/utils/email/google.tsapps/web/utils/gmail/mail.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/ai/actions.ts
🧬 Code graph analysis (2)
apps/web/utils/outlook/mail.ts (1)
apps/web/utils/email.ts (2)
extractEmailAddress(19-52)extractNameFromEmail(9-16)
apps/web/utils/gmail/mail.ts (1)
apps/web/utils/email/reply-all.ts (1)
formatCcList(67-69)
⏰ 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). (4)
- GitHub Check: Baz Reviewer
- GitHub Check: cubic · AI code reviewer
- GitHub Check: Macroscope - Correctness Check
- GitHub Check: test
🔇 Additional comments (6)
apps/web/utils/email/types.ts (1)
105-116: LGTM! Type definition correctly extended for CC/BCC support.The addition of optional
ccandbccfields to thedraftEmailmethod signature is clean and consistent with the existing pattern. This properly enables CC/BCC functionality across all email provider implementations.apps/web/utils/email/google.ts (1)
629-640: LGTM! Provider signature correctly updated.The
draftEmailmethod signature has been properly extended to accept optionalccandbccfields, maintaining consistency with theEmailProviderinterface and enabling these fields to be passed through to the Gmail implementation layer.apps/web/utils/gmail/mail.ts (1)
283-296: LGTM! Raw message creation correctly includes merged CC and BCC.The code properly:
- Formats the merged CC list using
formatCcList()which handles empty arrays- Passes through BCC with nullish coalescing to undefined
- Maintains the reply-all threading information
apps/web/utils/ai/actions.ts (1)
151-187: LGTM! Draft action correctly extended to support CC/BCC.The implementation properly:
- Adds
ccandbccto the action function signature with nullable string types- Converts null to undefined using nullish coalescing (consistent with other fields)
- Passes the fields through to
client.draftEmail()This enables AI-generated rules to specify CC/BCC recipients for draft replies.
apps/web/utils/outlook/mail.ts (1)
237-293: LGTM! BCC handling and draft update correctly implemented.The implementation properly:
- Parses BCC addresses and formats them for the Outlook API with both address and display name
- Uses conditional spread to only include
ccRecipientsandbccRecipientswhen they have content- Prevents sending empty arrays to the API
The defensive coding pattern here is excellent.
apps/web/utils/email/microsoft.ts (1)
486-497: LGTM! Provider signature correctly updated.The
draftEmailmethod signature has been properly extended to accept optionalccandbccfields, maintaining consistency with theEmailProviderinterface and enabling these fields to be passed through to the Outlook implementation layer.
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
2 issues found across 6 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/gmail/mail.ts">
<violation number="1" location="apps/web/utils/gmail/mail.ts:275">
P2: Email addresses from `args.cc` are not normalized before comparison. The `recipients.cc` array contains emails normalized via `extractEmailAddress()`, but `manualCc` only trims whitespace. This can cause duplicate CC entries when formats differ (e.g., `"John <john@example.com>"` vs `"john@example.com"`).</violation>
</file>
<file name="apps/web/utils/outlook/mail.ts">
<violation number="1" location="apps/web/utils/outlook/mail.ts:223">
P2: CC deduplication compares raw strings but should compare extracted email addresses. If `args.cc` contains `"John Doe <john@example.com>"` and `recipients.cc` already has `"john@example.com"`, the `includes()` check will fail (different string formats), causing duplicate CC recipients.</violation>
</file>
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
apps/web/utils/outlook/mail.ts
Outdated
| if (args.cc) { | ||
| const manualCc = args.cc.split(",").map((s) => s.trim()); | ||
| for (const email of manualCc) { | ||
| if (!ccAddresses.includes(email)) { |
There was a problem hiding this comment.
P2: CC deduplication compares raw strings but should compare extracted email addresses. If args.cc contains "John Doe <john@example.com>" and recipients.cc already has "john@example.com", the includes() check will fail (different string formats), causing duplicate CC recipients.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At apps/web/utils/outlook/mail.ts, line 223:
<comment>CC deduplication compares raw strings but should compare extracted email addresses. If `args.cc` contains `"John Doe <john@example.com>"` and `recipients.cc` already has `"john@example.com"`, the `includes()` check will fail (different string formats), causing duplicate CC recipients.</comment>
<file context>
@@ -213,14 +215,35 @@ export async function draftEmail(
+ if (args.cc) {
+ const manualCc = args.cc.split(",").map((s) => s.trim());
+ for (const email of manualCc) {
+ if (!ccAddresses.includes(email)) {
+ ccAddresses.push(email);
+ }
</file context>
✅ Addressed in dae6d57
There was a problem hiding this comment.
Fixed. Updated Outlook logic to use the same centralized deduplication utility that extracts email addresses before comparison.
There was a problem hiding this comment.
Commit dae6d57 addressed this comment by replacing the problematic raw string comparison logic with a centralized mergeAndDedupeRecipients utility function. This function properly extracts and compares email addresses before deduplication, eliminating the bug where different formats of the same email address would be treated as duplicates.
There was a problem hiding this comment.
Thanks for the feedback! I've saved this as a new learning to improve future reviews.
![baz-reviewer[bot]](https://avatars.githubusercontent.com/in/933528?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
apps/web/utils/email/reply-all.ts (2)
36-52: Remove unusedrawproperty for cleaner code.The
rawproperty is extracted but never used—onlyccSet. This adds unnecessary computation.🔎 Proposed refactor
if (headers.cc) { const originalCcAddresses = headers.cc .split(",") - .map((addr) => ({ - raw: addr.trim(), - email: extractEmailAddress(addr.trim()), - })) + .map((addr) => extractEmailAddress(addr.trim())) .filter( - ({ email }) => email && email !== replyTo && email !== currentUser, + (email) => email && email !== replyTo && email !== currentUser, ); - for (const { raw, email } of originalCcAddresses) { + for (const email of originalCcAddresses) { const key = email.toLowerCase(); if (!seenEmails.has(key)) { seenEmails.add(key); ccSet.add(email); } } }
57-73: Remove unusedrawproperty for cleaner code.Same issue as the CC section—the
rawproperty is extracted but never used.🔎 Proposed refactor
if (headers.to) { const originalToAddresses = headers.to .split(",") - .map((addr) => ({ - raw: addr.trim(), - email: extractEmailAddress(addr.trim()), - })) + .map((addr) => extractEmailAddress(addr.trim())) .filter( - ({ email }) => email && email !== replyTo && email !== currentUser, + (email) => email && email !== replyTo && email !== currentUser, ); - for (const { raw, email } of originalToAddresses) { + for (const email of originalToAddresses) { const key = email.toLowerCase(); if (!seenEmails.has(key)) { seenEmails.add(key); ccSet.add(email); } } }
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (8)
.cursor/commands/address-pr-comments.md.cursor/commands/create-pr.md.cursor/commands/next-step.md.cursor/commands/step-by-step.mdapps/web/utils/email/reply-all.test.tsapps/web/utils/email/reply-all.tsapps/web/utils/gmail/mail.tsapps/web/utils/outlook/mail.ts
✅ Files skipped from review due to trivial changes (3)
- .cursor/commands/address-pr-comments.md
- .cursor/commands/step-by-step.md
- .cursor/commands/next-step.md
🚧 Files skipped from review as they are similar to previous changes (1)
- apps/web/utils/outlook/mail.ts
🧰 Additional context used
📓 Path-based instructions (18)
**/*.{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/email/reply-all.tsapps/web/utils/email/reply-all.test.tsapps/web/utils/gmail/mail.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/email/reply-all.tsapps/web/utils/email/reply-all.test.tsapps/web/utils/gmail/mail.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
Files:
apps/web/utils/email/reply-all.tsapps/web/utils/email/reply-all.test.tsapps/web/utils/gmail/mail.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/email/reply-all.tsapps/web/utils/email/reply-all.test.tsapps/web/utils/gmail/mail.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/email/reply-all.tsapps/web/utils/email/reply-all.test.tsapps/web/utils/gmail/mail.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/email/reply-all.tsapps/web/utils/email/reply-all.test.tsapps/web/utils/gmail/mail.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/email/reply-all.tsapps/web/utils/email/reply-all.test.tsapps/web/utils/gmail/mail.ts
!(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/utils/email/reply-all.tsapps/web/utils/email/reply-all.test.ts.cursor/commands/create-pr.mdapps/web/utils/gmail/mail.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')
Files:
apps/web/utils/email/reply-all.tsapps/web/utils/email/reply-all.test.tsapps/web/utils/gmail/mail.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/email/reply-all.tsapps/web/utils/email/reply-all.test.tsapps/web/utils/gmail/mail.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
Prefer self-documenting code over comments; use descriptive variable and function names instead of explaining intent with comments
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/email/reply-all.tsapps/web/utils/email/reply-all.test.tsapps/web/utils/gmail/mail.ts
apps/web/**/*.{ts,tsx,js,jsx,json,css}
📄 CodeRabbit inference engine (apps/web/CLAUDE.md)
Format code with Prettier
Files:
apps/web/utils/email/reply-all.tsapps/web/utils/email/reply-all.test.tsapps/web/utils/gmail/mail.ts
apps/web/**/*.{example,ts,json}
📄 CodeRabbit inference engine (apps/web/CLAUDE.md)
Add environment variables to
.env.example,env.ts, andturbo.json
Files:
apps/web/utils/email/reply-all.tsapps/web/utils/email/reply-all.test.tsapps/web/utils/gmail/mail.ts
**/*.test.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/testing.mdc)
**/*.test.{ts,tsx}: Usevitestfor testing the application
Tests should be colocated next to the tested file with.test.tsor.test.tsxextension (e.g.,dir/format.tsanddir/format.test.ts)
Mockserver-onlyusingvi.mock("server-only", () => ({}))
Mock Prisma usingvi.mock("@/utils/prisma")and import the mock from@/utils/__mocks__/prisma
Usevi.clearAllMocks()inbeforeEachto clean up mocks between tests
Each test should be independent
Use descriptive test names
Mock external dependencies in tests
Do not mock the Logger
Avoid testing implementation details
Use test helpersgetEmail,getEmailAccount, andgetRulefrom@/__tests__/helpersfor mocking emails, accounts, and rules
Files:
apps/web/utils/email/reply-all.test.ts
**/*.{test,spec}.{js,jsx,ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/ultracite.mdc)
**/*.{test,spec}.{js,jsx,ts,tsx}: Don't nest describe() blocks too deeply in test files
Don't use callbacks in asynchronous tests and hooks
Don't have duplicate hooks in describe blocks
Don't use export or module.exports in test files
Don't use focused tests
Make sure the assertion function, like expect, is placed inside an it() function call
Don't use disabled tests
Files:
apps/web/utils/email/reply-all.test.ts
apps/web/**/*.test.{ts,tsx}
📄 CodeRabbit inference engine (apps/web/CLAUDE.md)
Co-locate test files next to source files (e.g.,
utils/example.test.ts). Only E2E and AI tests go in__tests__/
Files:
apps/web/utils/email/reply-all.test.ts
**/*.test.{js,jsx,ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/notes.mdc)
Co-locate test files next to source files (e.g.,
utils/example.test.ts). Only E2E and AI tests go in__tests__/
Files:
apps/web/utils/email/reply-all.test.ts
apps/web/utils/gmail/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/gmail-api.mdc)
apps/web/utils/gmail/**/*.{ts,tsx}: Always use wrapper functions from @/utils/gmail/ for Gmail API operations instead of direct provider API calls
Keep Gmail provider-specific implementation details isolated within the apps/web/utils/gmail/ directory
Files:
apps/web/utils/gmail/mail.ts
🧠 Learnings (13)
📓 Common learnings
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: Design Gmail wrapper functions to be provider-agnostic to support future email providers like Outlook and ProtonMail
📚 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/utils/email/reply-all.tsapps/web/utils/email/reply-all.test.tsapps/web/utils/gmail/mail.ts
📚 Learning: 2025-11-25T14:37:56.430Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/llm-test.mdc:0-0
Timestamp: 2025-11-25T14:37:56.430Z
Learning: Applies to apps/web/__tests__/**/*.test.ts : Prefer using existing helpers from `@/__tests__/helpers.ts` (`getEmailAccount`, `getEmail`, `getRule`, `getMockMessage`, `getMockExecutedRule`) instead of creating custom test data helpers
Applied to files:
apps/web/utils/email/reply-all.test.ts
📚 Learning: 2025-11-25T14:40:00.833Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-11-25T14:40:00.833Z
Learning: Applies to **/*.test.{ts,tsx} : Use test helpers `getEmail`, `getEmailAccount`, and `getRule` from `@/__tests__/helpers` for mocking emails, accounts, and rules
Applied to files:
apps/web/utils/email/reply-all.test.tsapps/web/utils/gmail/mail.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/utils/email/reply-all.test.tsapps/web/utils/gmail/mail.ts
📚 Learning: 2025-11-25T14:37:56.430Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/llm-test.mdc:0-0
Timestamp: 2025-11-25T14:37:56.430Z
Learning: Applies to apps/web/__tests__/**/*.test.ts : Use vitest imports (`describe`, `expect`, `test`, `vi`, `beforeEach`) in LLM test files
Applied to files:
apps/web/utils/email/reply-all.test.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/utils/gmail/mail.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/utils/gmail/mail.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} : Always use wrapper functions from @/utils/gmail/ for Gmail API operations instead of direct provider API calls
Applied to files:
apps/web/utils/gmail/mail.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/gmail/mail.ts
📚 Learning: 2025-11-25T14:42:11.919Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/utilities.mdc:0-0
Timestamp: 2025-11-25T14:42:11.919Z
Learning: Applies to utils/**/*.{js,ts,jsx,tsx} : The `utils` folder contains core app logic such as Next.js Server Actions and Gmail API requests
Applied to files:
apps/web/utils/gmail/mail.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: Design Gmail wrapper functions to be provider-agnostic to support future email providers like Outlook and ProtonMail
Applied to files:
apps/web/utils/gmail/mail.ts
📚 Learning: 2025-11-25T14:42:16.602Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/utilities.mdc:0-0
Timestamp: 2025-11-25T14:42:16.602Z
Learning: The `utils` folder contains core app logic such as Next.js Server Actions and Gmail API requests
Applied to files:
apps/web/utils/gmail/mail.ts
🧬 Code graph analysis (3)
apps/web/utils/email/reply-all.ts (1)
apps/web/utils/email.ts (1)
extractEmailAddress(19-52)
apps/web/utils/email/reply-all.test.ts (1)
apps/web/utils/email/reply-all.ts (1)
mergeAndDedupeRecipients(94-120)
apps/web/utils/gmail/mail.ts (1)
apps/web/utils/email/reply-all.ts (2)
mergeAndDedupeRecipients(94-120)formatCcList(86-88)
⏰ 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: Macroscope - Correctness Check
🔇 Additional comments (3)
apps/web/utils/email/reply-all.test.ts (1)
412-433: LGTM! Comprehensive test coverage for the new helper.The test suite properly validates display-name handling, case-insensitive deduplication, and sanitization of invalid entries—all critical behaviors for the CC/BCC merging logic.
apps/web/utils/gmail/mail.ts (1)
276-285: LGTM! CC/BCC merging and sanitization are correctly implemented.The code properly merges reply-all CCs with manual CCs using
mergeAndDedupeRecipients, and sanitizes BCCs. The helper handles normalization, case-insensitive deduplication, and filtering of invalid entries.apps/web/utils/email/reply-all.ts (1)
94-120: LGTM! Well-designed deduplication helper.The function properly handles email normalization, case-insensitive deduplication, and sanitization while preserving original formatting (display names). The implementation aligns with the test coverage and addresses the CC/BCC propagation requirements.
1 participant
User description
assistant: fix CC/BCC recipients not being added to draft replies
Fixes a bug where CC/BCC recipients configured in rules were not passed to the draft creation logic.
Generated description
Below is a concise technical summary of the changes proposed in this PR:
Resolves a bug preventing CC/BCC recipients from being included in draft replies by extending the
EmailProvider.draftEmailinterface to support these fields. Integrates a newmergeAndDedupeRecipientsutility within theGmailProviderandOutlookProviderimplementations to correctly combine and deduplicate recipients, ensuring that AI actions can now successfully pass configured CC/BCC addresses to the email drafting logic.EmailProviderinterface, modifying the AI action handler to pass these fields, and adapting theGmailProviderandOutlookProviderimplementations to utilize the new recipient merging logic for draft email creation.Modified files (6)
Latest Contributors(2)
mergeAndDedupeRecipientsto combine and deduplicate email addresses from various sources, ensuring proper sanitization and case-insensitivity. Additionally, enhance thebuildReplyAllRecipientsfunction to improve the robustness of CC list generation for reply-all scenarios, and add comprehensive unit tests for the new merging utility.Modified files (2)
Latest Contributors(2)
pnpm test.Modified files (5)
Latest Contributors(1)