Merged
Conversation
|
@miha-yy is attempting to deploy a commit to the Inbox Zero Team on Vercel. A member of the Team first needs to authorize it. |
|
|
Contributor
WalkthroughThis change refactors the email provider abstraction across the codebase, introducing provider-agnostic interfaces and middleware, centralizing provider-specific logic, and updating API routes and controllers accordingly. It also generalizes environment variables for encryption, updates documentation, and refines types and function signatures to support both Google and Microsoft email providers uniformly. Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant API_Route
participant Middleware
participant DB
participant EmailProvider
participant Controller
Client->>API_Route: HTTP Request (e.g., /api/messages)
API_Route->>Middleware: withEmailProvider
Middleware->>DB: Fetch email account & provider
Middleware->>EmailProvider: Create provider instance
Middleware->>API_Route: Inject emailProvider
API_Route->>Controller: Call provider-agnostic method (e.g., getMessages)
Controller->>EmailProvider: Perform action (e.g., fetch messages)
EmailProvider-->>Controller: Result
Controller-->>API_Route: Response data
API_Route-->>Client: JSON Response
sequenceDiagram
participant CronJob
participant WatchAllRoute
participant DB
participant EmailProvider
participant WatchController
CronJob->>WatchAllRoute: Trigger /api/watch/all (GET/POST)
WatchAllRoute->>DB: Query all premium email accounts
loop For each account
WatchAllRoute->>EmailProvider: Create provider instance
WatchAllRoute->>WatchController: watchEmails(emailAccountId, provider)
WatchController->>EmailProvider: provider.watchEmails()
EmailProvider-->>WatchController: Expiration/subscription info
WatchController-->>WatchAllRoute: Success/failure
end
WatchAllRoute-->>CronJob: JSON summary response
Possibly related PRs
Poem
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
apps/web/app/api/watch/route.tsOops! Something went wrong! :( ESLint: 9.28.0 ESLint couldn't find an eslint.config.(js|mjs|cjs) file. From ESLint v9.0.0, the default configuration file is now eslint.config.js. https://eslint.org/docs/latest/use/configure/migration-guide If you still have problems after following the migration guide, please stop by ✨ 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. 🪧 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
|
![jit-ci[bot]](https://avatars.githubusercontent.com/in/142441?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 4
🔭 Outside diff range comments (2)
apps/web/components/GroupedTable.tsx (2)
138-138: Gmail-specific URL function contradicts provider-agnostic approach.The code still uses
getGmailSearchUrlwhich is Gmail-specific, contradicting the provider-agnostic refactor. Consider using a generic email search URL function.
524-524: Inconsistent provider usage - still destructuring but not available.The
ExpandedRowscomponent still tries to destructureproviderfromuseAccount(), but it was removed from the hook's return at line 78. This will cause a runtime error.Apply this diff to fix the inconsistency:
-const { provider } = useAccount(); +// Provider is now handled by the email provider abstractionAnd update the
getEmailUrlcall at line 572 to not pass the provider parameter.
🧹 Nitpick comments (14)
apps/web/package.json (2)
123-124: Duplicate “prettier” entry – keep it in one section only
prettierappears in bothdependencies(line 123) anddevDependencies(line 171).
It’s build-time tooling, so leaving it only underdevDependenciesavoids unnecessary prod bloat and potential version drift.@@ - "prettier": "3.5.3", @@ - "prettier": "3.5.3", + "prettier": "3.5.3",(Delete the earlier occurrence in
"dependencies".)Also applies to: 171-172
94-96: ESLint should be a devDependency, not a runtime dependency
eslintandeslint-config-nextare bundled into production right now. They are never required at runtime and add ~20 MB of node_modules footprint.Move the two packages from
"dependencies"to"devDependencies". No code change required elsewhere.apps/web/app/(landing)/login/LoginForm.tsx (1)
79-105: Consider UI consistency between Google and Microsoft sign-in flows.The Microsoft sign-in button now directly triggers authentication without the dialog that's still present for Google sign-in. This creates an inconsistent user experience where Google users see a consent dialog with policy information and an "I agree" button, while Microsoft users don't.
Consider either:
- Adding a similar consent dialog for Microsoft users
- Removing the dialog for Google users if the consent step isn't legally required
- Documenting this intentional difference if it's by design
apps/web/app/(app)/[emailAccountId]/assistant/ExecutedRulesTable.tsx (1)
174-194: Consider renaming the component to reflect multi-provider support.The
OpenInGmailButtoncomponent now works with multiple email providers, but the name is still Gmail-specific. While the functionality is correctly implemented using the provider abstraction, the component name is misleading.Consider renaming to something more generic like
OpenInEmailButtonorOpenEmailExternallyButtonto better reflect its multi-provider capability:-function OpenInGmailButton({ +function OpenInEmailButton({ messageId, threadId, userEmail, }: { messageId: string; threadId: string; userEmail: string; }) {And update the usage accordingly:
- <OpenInGmailButton + <OpenInEmailButton messageId={messageId} threadId={threadId} userEmail={userEmail} />apps/web/app/api/messages/route.ts (1)
7-7: Use import type for type-only importsThe
EmailProviderimport is only used as a type and should be imported withimport typeto ensure it's removed during compilation.Apply this fix:
-import { EmailProvider } from "@/utils/email/provider"; +import type { EmailProvider } from "@/utils/email/provider";apps/web/app/api/user/stats/newsletters/route.ts (1)
8-8: Useimport typefor type-only imports.The
EmailProvideris only used as a type in this file.-import { EmailProvider } from "@/utils/email/provider"; +import type { EmailProvider } from "@/utils/email/provider";apps/web/app/api/messages/batch/route.ts (1)
5-5: Useimport typefor type-only imports.The
EmailProvideris only used as a type in this file.-import { EmailProvider } from "@/utils/email/provider"; +import type { EmailProvider } from "@/utils/email/provider";apps/web/app/api/watch/controller.ts (1)
49-90: Robust unwatch implementation with proper cleanup.Good defensive programming to always clear watch data regardless of provider unwatch success. The special handling for
invalid_granterrors is appropriate.Consider simplifying the null/undefined conversion:
- await provider.unwatchEmails(subscriptionId || undefined); + await provider.unwatchEmails(subscriptionId ?? undefined);apps/web/app/api/threads/[id]/route.ts (1)
5-5: Useimport typefor type-only imports.-import { EmailProvider } from "@/utils/email/provider"; +import type { EmailProvider } from "@/utils/email/provider";apps/web/providers/EmailProvider.tsx (1)
34-37: Consider removing redundant provider checkThe
!providercheck is redundant since the calling code already ensures provider exists before calling this function (line 61).function mapLabelColor(provider: string, label: any): EmailLabel["color"] { - if (!provider) { - return undefined; - } - if (provider === "google") {apps/web/app/api/threads/route.ts (1)
3-3: Use import type for type-only importsStatic analysis correctly identifies that these imports are only used as types.
-import { ThreadsQuery, threadsQuery } from "@/app/api/threads/validation"; +import { type ThreadsQuery, threadsQuery } from "@/app/api/threads/validation";-import { EmailProvider } from "@/utils/email/provider"; +import type { EmailProvider } from "@/utils/email/provider";Also applies to: 10-10
apps/web/utils/url.ts (1)
9-38: Consider using a const assertion for better type safety.The
PROVIDER_CONFIGis typed asRecord<string, ...>which allows any string key, but you only use specific providers. Consider using a const assertion with satisfies for better type safety:-const PROVIDER_CONFIG: Record< - string, - { - buildUrl: ( - messageOrThreadId: string, - emailAddress?: string | null, - ) => string; - selectId: (messageId: string, threadId: string) => string; - } -> = { +const PROVIDER_CONFIG = { "microsoft-entra-id": { buildUrl: (messageOrThreadId: string, emailAddress?: string | null) => { // Outlook URL format: https://outlook.live.com/mail/0/inbox/id/ENCODED_MESSAGE_ID // The message ID needs to be URL-encoded for Outlook const encodedMessageId = encodeURIComponent(messageOrThreadId); return `${getOutlookBaseUrl()}/inbox/id/${encodedMessageId}`; }, selectId: (messageId: string, threadId: string) => threadId, }, google: { buildUrl: (messageOrThreadId: string, emailAddress?: string | null) => `${getGmailBaseUrl(emailAddress)}/#all/${messageOrThreadId}`, selectId: (messageId: string, threadId: string) => messageId, }, default: { buildUrl: (messageOrThreadId: string, emailAddress?: string | null) => `${getGmailBaseUrl(emailAddress)}/#all/${messageOrThreadId}`, selectId: (messageId: string, threadId: string) => threadId, }, -} as const; +} as const satisfies Record< + string, + { + buildUrl: ( + messageOrThreadId: string, + emailAddress?: string | null, + ) => string; + selectId: (messageId: string, threadId: string) => string; + } +>;apps/web/utils/email/provider.ts (2)
260-275: Consider adding JSDoc documentation for the new webhook methods.The new webhook-related methods would benefit from documentation explaining their purpose, parameters, and return values:
+ /** + * Process email history updates from webhook notifications + * @param options - Provider-specific options for history processing + */ processHistory(options: { emailAddress: string; historyId?: number; startHistoryId?: number; subscriptionId?: string; resourceData?: { id: string; conversationId?: string; }; }): Promise<void>; + /** + * Subscribe to email updates via webhooks + * @returns Subscription details including expiration date and optional subscription ID + */ watchEmails(): Promise<{ expirationDate: Date; subscriptionId?: string; } | null>; + /** + * Unsubscribe from email updates + * @param subscriptionId - Optional subscription ID (required for some providers) + */ unwatchEmails(subscriptionId?: string): Promise<void>;
1605-1611: Consider making subscriptionId required for Outlook's unwatchEmails.Since Outlook requires a subscription ID to unwatch, consider making the parameter required instead of optional to catch issues at compile time:
- async unwatchEmails(subscriptionId?: string): Promise<void> { - if (!subscriptionId) { - logger.warn("No subscription ID provided for Outlook unwatch"); - return; - } - await unwatchOutlook(this.client.getClient(), subscriptionId); - } + async unwatchEmails(subscriptionId: string): Promise<void> { + await unwatchOutlook(this.client.getClient(), subscriptionId); + }However, this would require updating the interface to support provider-specific signatures, which might not be desirable for the abstraction.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (50)
.github/workflows/test.yml(1 hunks)README.md(4 hunks)apps/web/app/(app)/[emailAccountId]/PermissionsCheck.tsx(2 hunks)apps/web/app/(app)/[emailAccountId]/assistant/ExecutedRulesTable.tsx(4 hunks)apps/web/app/(app)/[emailAccountId]/assistant/ProcessRules.tsx(1 hunks)apps/web/app/(app)/[emailAccountId]/bulk-unsubscribe/hooks.ts(4 hunks)apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx(2 hunks)apps/web/app/(landing)/login/LoginForm.tsx(1 hunks)apps/web/app/api/google/webhook/process-history.ts(4 hunks)apps/web/app/api/labels/create/route.ts(1 hunks)apps/web/app/api/labels/route.ts(2 hunks)apps/web/app/api/messages/attachment/route.ts(1 hunks)apps/web/app/api/messages/batch/route.ts(3 hunks)apps/web/app/api/messages/route.ts(6 hunks)apps/web/app/api/outlook/webhook/process-history.ts(4 hunks)apps/web/app/api/threads/[id]/route.ts(4 hunks)apps/web/app/api/threads/basic/route.ts(1 hunks)apps/web/app/api/threads/batch/route.ts(2 hunks)apps/web/app/api/threads/route.ts(1 hunks)apps/web/app/api/threads/validation.ts(0 hunks)apps/web/app/api/user/stats/newsletters/helpers.ts(3 hunks)apps/web/app/api/user/stats/newsletters/route.ts(7 hunks)apps/web/app/api/watch/all/route.ts(1 hunks)apps/web/app/api/watch/controller.ts(1 hunks)apps/web/app/api/watch/route.ts(1 hunks)apps/web/app/api/watch/unwatch/route.ts(1 hunks)apps/web/components/EmailMessageCell.tsx(2 hunks)apps/web/components/GroupedTable.tsx(2 hunks)apps/web/components/SideNav.tsx(1 hunks)apps/web/env.ts(1 hunks)apps/web/hooks/useLabels.ts(1 hunks)apps/web/hooks/useThreads.ts(0 hunks)apps/web/package.json(1 hunks)apps/web/providers/EmailProvider.tsx(2 hunks)apps/web/store/archive-sender-queue.ts(1 hunks)apps/web/utils/actions/admin.ts(3 hunks)apps/web/utils/auth.ts(1 hunks)apps/web/utils/email/provider.ts(8 hunks)apps/web/utils/encryption.test.ts(1 hunks)apps/web/utils/encryption.ts(1 hunks)apps/web/utils/middleware.ts(4 hunks)apps/web/utils/outlook/client.ts(3 hunks)apps/web/utils/outlook/filter.ts(1 hunks)apps/web/utils/outlook/label.ts(2 hunks)apps/web/utils/outlook/spam.ts(1 hunks)apps/web/utils/outlook/trash.ts(1 hunks)apps/web/utils/url.ts(1 hunks)apps/web/utils/user/delete.ts(3 hunks)docker/Dockerfile.prod(1 hunks)turbo.json(2 hunks)
💤 Files with no reviewable changes (2)
- apps/web/hooks/useThreads.ts
- apps/web/app/api/threads/validation.ts
🧰 Additional context used
📓 Path-based instructions (10)
`apps/web/**/*.{ts,tsx}`: Use TypeScript with strict null checks Path aliases: U...
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
📄 Source: CodeRabbit Inference Engine (apps/web/CLAUDE.md)
List of files the instruction was applied to:
apps/web/app/(app)/[emailAccountId]/PermissionsCheck.tsxapps/web/utils/outlook/label.tsapps/web/components/SideNav.tsxapps/web/utils/outlook/spam.tsapps/web/utils/outlook/filter.tsapps/web/utils/encryption.test.tsapps/web/utils/encryption.tsapps/web/components/GroupedTable.tsxapps/web/store/archive-sender-queue.tsapps/web/app/(app)/[emailAccountId]/assistant/ProcessRules.tsxapps/web/hooks/useLabels.tsapps/web/app/api/messages/attachment/route.tsapps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsxapps/web/utils/outlook/trash.tsapps/web/app/(landing)/login/LoginForm.tsxapps/web/app/api/outlook/webhook/process-history.tsapps/web/utils/outlook/client.tsapps/web/app/api/google/webhook/process-history.tsapps/web/components/EmailMessageCell.tsxapps/web/utils/auth.tsapps/web/utils/actions/admin.tsapps/web/app/api/labels/route.tsapps/web/env.tsapps/web/app/api/labels/create/route.tsapps/web/app/api/threads/basic/route.tsapps/web/app/api/threads/[id]/route.tsapps/web/app/api/threads/batch/route.tsapps/web/app/api/user/stats/newsletters/route.tsapps/web/utils/user/delete.tsapps/web/app/(app)/[emailAccountId]/assistant/ExecutedRulesTable.tsxapps/web/app/(app)/[emailAccountId]/bulk-unsubscribe/hooks.tsapps/web/app/api/messages/route.tsapps/web/app/api/watch/unwatch/route.tsapps/web/app/api/user/stats/newsletters/helpers.tsapps/web/app/api/watch/route.tsapps/web/utils/middleware.tsapps/web/providers/EmailProvider.tsxapps/web/app/api/messages/batch/route.tsapps/web/utils/url.tsapps/web/app/api/threads/route.tsapps/web/app/api/watch/all/route.tsapps/web/utils/email/provider.tsapps/web/app/api/watch/controller.ts
`apps/web/app/**/*`: NextJS app router structure with (app) directory
apps/web/app/**/*: NextJS app router structure with (app) directory
📄 Source: CodeRabbit Inference Engine (apps/web/CLAUDE.md)
List of files the instruction was applied to:
apps/web/app/(app)/[emailAccountId]/PermissionsCheck.tsxapps/web/app/(app)/[emailAccountId]/assistant/ProcessRules.tsxapps/web/app/api/messages/attachment/route.tsapps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsxapps/web/app/(landing)/login/LoginForm.tsxapps/web/app/api/outlook/webhook/process-history.tsapps/web/app/api/google/webhook/process-history.tsapps/web/app/api/labels/route.tsapps/web/app/api/labels/create/route.tsapps/web/app/api/threads/basic/route.tsapps/web/app/api/threads/[id]/route.tsapps/web/app/api/threads/batch/route.tsapps/web/app/api/user/stats/newsletters/route.tsapps/web/app/(app)/[emailAccountId]/assistant/ExecutedRulesTable.tsxapps/web/app/(app)/[emailAccountId]/bulk-unsubscribe/hooks.tsapps/web/app/api/messages/route.tsapps/web/app/api/watch/unwatch/route.tsapps/web/app/api/user/stats/newsletters/helpers.tsapps/web/app/api/watch/route.tsapps/web/app/api/messages/batch/route.tsapps/web/app/api/threads/route.tsapps/web/app/api/watch/all/route.tsapps/web/app/api/watch/controller.ts
`apps/web/**/*.tsx`: Follow tailwindcss patterns with prettier-plugin-tailwindcs...
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
📄 Source: CodeRabbit Inference Engine (apps/web/CLAUDE.md)
List of files the instruction was applied to:
apps/web/app/(app)/[emailAccountId]/PermissionsCheck.tsxapps/web/components/SideNav.tsxapps/web/components/GroupedTable.tsxapps/web/app/(app)/[emailAccountId]/assistant/ProcessRules.tsxapps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsxapps/web/app/(landing)/login/LoginForm.tsxapps/web/components/EmailMessageCell.tsxapps/web/app/(app)/[emailAccountId]/assistant/ExecutedRulesTable.tsxapps/web/providers/EmailProvider.tsx
`**/*.tsx`: For API GET requests to server, use the `swr` package Use `result?.serverError` with `toastError` and `toastSuccess` for error handling; success toast is optional
**/*.tsx: For API GET requests to server, use theswrpackage
Useresult?.serverErrorwithtoastErrorandtoastSuccessfor error handling; success toast is optional
📄 Source: CodeRabbit Inference Engine (.cursor/rules/data-fetching.mdc)
List of files the instruction was applied to:
apps/web/app/(app)/[emailAccountId]/PermissionsCheck.tsxapps/web/components/SideNav.tsxapps/web/components/GroupedTable.tsxapps/web/app/(app)/[emailAccountId]/assistant/ProcessRules.tsxapps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsxapps/web/app/(landing)/login/LoginForm.tsxapps/web/components/EmailMessageCell.tsxapps/web/app/(app)/[emailAccountId]/assistant/ExecutedRulesTable.tsxapps/web/providers/EmailProvider.tsx
`**/*.tsx`: Use React Hook Form with Zod for validation Validate form inputs before submission Show validation errors inline next to form fields
**/*.tsx: Use React Hook Form with Zod for validation
Validate form inputs before submission
Show validation errors inline next to form fields
📄 Source: CodeRabbit Inference Engine (.cursor/rules/form-handling.mdc)
List of files the instruction was applied to:
apps/web/app/(app)/[emailAccountId]/PermissionsCheck.tsxapps/web/components/SideNav.tsxapps/web/components/GroupedTable.tsxapps/web/app/(app)/[emailAccountId]/assistant/ProcessRules.tsxapps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsxapps/web/app/(landing)/login/LoginForm.tsxapps/web/components/EmailMessageCell.tsxapps/web/app/(app)/[emailAccountId]/assistant/ExecutedRulesTable.tsxapps/web/providers/EmailProvider.tsx
`**/*.{ts,tsx}`: Define validation schemas using Zod Apply the same validation in both client and server Use descriptive error messages
**/*.{ts,tsx}: Define validation schemas using Zod
Apply the same validation in both client and server
Use descriptive error messages
📄 Source: CodeRabbit Inference Engine (.cursor/rules/form-handling.mdc)
List of files the instruction was applied to:
apps/web/app/(app)/[emailAccountId]/PermissionsCheck.tsxapps/web/utils/outlook/label.tsapps/web/components/SideNav.tsxapps/web/utils/outlook/spam.tsapps/web/utils/outlook/filter.tsapps/web/utils/encryption.test.tsapps/web/utils/encryption.tsapps/web/components/GroupedTable.tsxapps/web/store/archive-sender-queue.tsapps/web/app/(app)/[emailAccountId]/assistant/ProcessRules.tsxapps/web/hooks/useLabels.tsapps/web/app/api/messages/attachment/route.tsapps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsxapps/web/utils/outlook/trash.tsapps/web/app/(landing)/login/LoginForm.tsxapps/web/app/api/outlook/webhook/process-history.tsapps/web/utils/outlook/client.tsapps/web/app/api/google/webhook/process-history.tsapps/web/components/EmailMessageCell.tsxapps/web/utils/auth.tsapps/web/utils/actions/admin.tsapps/web/app/api/labels/route.tsapps/web/env.tsapps/web/app/api/labels/create/route.tsapps/web/app/api/threads/basic/route.tsapps/web/app/api/threads/[id]/route.tsapps/web/app/api/threads/batch/route.tsapps/web/app/api/user/stats/newsletters/route.tsapps/web/utils/user/delete.tsapps/web/app/(app)/[emailAccountId]/assistant/ExecutedRulesTable.tsxapps/web/app/(app)/[emailAccountId]/bulk-unsubscribe/hooks.tsapps/web/app/api/messages/route.tsapps/web/app/api/watch/unwatch/route.tsapps/web/app/api/user/stats/newsletters/helpers.tsapps/web/app/api/watch/route.tsapps/web/utils/middleware.tsapps/web/providers/EmailProvider.tsxapps/web/app/api/messages/batch/route.tsapps/web/utils/url.tsapps/web/app/api/threads/route.tsapps/web/app/api/watch/all/route.tsapps/web/utils/email/provider.tsapps/web/app/api/watch/controller.ts
`turbo.json`: Add all new environment variables to the `env` array under the `build` task in `turbo.json`
turbo.json: Add all new environment variables to theenvarray under thebuildtask inturbo.json
📄 Source: CodeRabbit Inference Engine (.cursor/rules/environment-variables.mdc)
List of files the instruction was applied to:
turbo.json
`apps/web/**/{.env.example,env.ts,turbo.json}`: Add environment variables to `.env.example`, `env.ts`, and `turbo.json`
apps/web/**/{.env.example,env.ts,turbo.json}: Add environment variables to.env.example,env.ts, andturbo.json
📄 Source: CodeRabbit Inference Engine (apps/web/CLAUDE.md)
List of files the instruction was applied to:
apps/web/env.ts
`apps/web/**/{.env.example,env.ts}`: Client-side environment variables must be prefixed with `NEXT_PUBLIC_`
apps/web/**/{.env.example,env.ts}: Client-side environment variables must be prefixed withNEXT_PUBLIC_
📄 Source: CodeRabbit Inference Engine (apps/web/CLAUDE.md)
List of files the instruction was applied to:
apps/web/env.ts
`apps/web/env.ts`: For server-only environment variables, add them to the `serve...
apps/web/env.ts: For server-only environment variables, add them to theserversection inapps/web/env.ts
For client-side environment variables, prefix them withNEXT_PUBLIC_and add them to both theclientandexperimental__runtimeEnvsections inapps/web/env.ts
📄 Source: CodeRabbit Inference Engine (.cursor/rules/environment-variables.mdc)
List of files the instruction was applied to:
apps/web/env.ts
🧠 Learnings (49)
📓 Common learnings
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Keep provider-specific implementation details isolated within their respective utility directories (e.g., apps/web/utils/gmail/ for Gmail), which allows for easier addition of new providers in the future.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Never call provider APIs (such as Gmail) directly from routes or components; always use abstraction layers provided by utility wrapper functions.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Always use wrapper functions from the utils folder (e.g., apps/web/utils/gmail/message.ts) to interact with provider APIs, ensuring maintainability and easier future provider support.
Learnt from: elie222
PR: elie222/inbox-zero#537
File: apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx:30-34
Timestamp: 2025-07-08T13:14:07.449Z
Learning: The clean onboarding page in apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx is intentionally Gmail-specific and should show an error for non-Google email accounts rather than attempting to support multiple providers.
apps/web/app/(app)/[emailAccountId]/PermissionsCheck.tsx (10)
Learnt from: elie222
PR: elie222/inbox-zero#537
File: apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx:30-34
Timestamp: 2025-07-08T13:14:07.449Z
Learning: The clean onboarding page in apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx is intentionally Gmail-specific and should show an error for non-Google email accounts rather than attempting to support multiple providers.
Learnt from: CR
PR: elie222/inbox-zero#0
File: apps/web/CLAUDE.md:0-0
Timestamp: 2025-07-03T12:02:16.137Z
Learning: Applies to apps/web/**/*.tsx : Prefer functional components with hooks
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: In Next.js App Router, GET API route handlers should be wrapped with either `withAuth` or `withEmailAccount` middleware to ensure consistent error handling and authentication.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: In Next.js API routes under apps/web/app/api/, always use authentication middleware such as withAuth or withEmailAccount, or ensure custom authentication logic is present if using withError.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-06-23T12:27:17.978Z
Learning: In Next.js/TypeScript API routes, always use authentication middleware (withAuth for user-level, withEmailAccount for account-level) to protect endpoints that handle user data.
Learnt from: elie222
PR: elie222/inbox-zero#485
File: apps/web/app/(landing)/login/page.tsx:41-43
Timestamp: 2025-06-05T09:49:12.168Z
Learning: In Next.js App Router, components that use the `useSearchParams` hook require a Suspense boundary to handle the asynchronous nature of search parameter access. The Suspense wrapper is necessary and should not be removed when a component uses useSearchParams.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/project-structure.mdc:0-0
Timestamp: 2025-06-23T12:26:59.468Z
Learning: For components with onClick handlers in Next.js App Router, ensure they are client components by including the 'use client' directive at the top of the file.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: All Prisma queries in API routes must be scoped to the current user or account by including emailAccountId or userId in the WHERE clause to prevent unauthorized data access (IDOR vulnerabilities).
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-06-23T12:27:17.978Z
Learning: Database queries in API routes must always include user/account scoping (e.g., userId, emailAccountId) to prevent unauthorized data access and IDOR vulnerabilities.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Never call provider APIs (such as Gmail) directly from routes or components; always use abstraction layers provided by utility wrapper functions.
apps/web/utils/outlook/label.ts (5)
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/form-handling.mdc:0-0
Timestamp: 2025-07-03T12:02:53.001Z
Learning: Applies to **/*.{ts,tsx} : Use descriptive error messages
Learnt from: CR
PR: elie222/inbox-zero#0
File: apps/web/CLAUDE.md:0-0
Timestamp: 2025-07-03T12:02:16.137Z
Learning: Applies to apps/web/**/types/**/*.{ts,d.ts} : Centralize types in dedicated type files when shared
Learnt from: elie222
PR: elie222/inbox-zero#537
File: apps/web/app/api/user/stats/newsletters/route.ts:235-239
Timestamp: 2025-07-08T13:14:03.250Z
Learning: The user prefers proper TypeScript error type checking (using `error instanceof Error`) over type assertions with `as any` for better type safety and code quality.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/llm.mdc:0-0
Timestamp: 2025-06-23T12:26:36.694Z
Learning: Use TypeScript types for all parameters and return values, and define clear interfaces for complex input and output structures to ensure type safety.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Always use wrapper functions from the utils folder (e.g., apps/web/utils/gmail/message.ts) to interact with provider APIs, ensuring maintainability and easier future provider support.
apps/web/components/SideNav.tsx (5)
Learnt from: elie222
PR: elie222/inbox-zero#537
File: apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx:30-34
Timestamp: 2025-07-08T13:14:07.449Z
Learning: The clean onboarding page in apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx is intentionally Gmail-specific and should show an error for non-Google email accounts rather than attempting to support multiple providers.
Learnt from: CR
PR: elie222/inbox-zero#0
File: apps/web/CLAUDE.md:0-0
Timestamp: 2025-07-03T12:02:16.137Z
Learning: Applies to apps/web/**/*.tsx : Use shadcn/ui components when available
Learnt from: CR
PR: elie222/inbox-zero#0
File: apps/web/CLAUDE.md:0-0
Timestamp: 2025-07-03T12:02:16.137Z
Learning: Applies to apps/web/**/*.tsx : Prefer functional components with hooks
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Always use wrapper functions from the utils folder (e.g., apps/web/utils/gmail/message.ts) to interact with provider APIs, ensuring maintainability and easier future provider support.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-06-23T12:27:17.978Z
Learning: In Next.js/TypeScript API routes, always use authentication middleware (withAuth for user-level, withEmailAccount for account-level) to protect endpoints that handle user data.
apps/web/utils/outlook/spam.ts (2)
Learnt from: elie222
PR: elie222/inbox-zero#537
File: apps/web/app/api/user/stats/newsletters/route.ts:235-239
Timestamp: 2025-07-08T13:14:03.250Z
Learning: The user prefers proper TypeScript error type checking (using `error instanceof Error`) over type assertions with `as any` for better type safety and code quality.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/form-handling.mdc:0-0
Timestamp: 2025-07-03T12:02:53.001Z
Learning: Applies to **/*.{ts,tsx} : Use descriptive error messages
docker/Dockerfile.prod (8)
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: Do not hardcode secrets directly in code for cron endpoints; secrets should be managed via environment variables (e.g., CRON_SECRET) and not as plain strings in the source code.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-06-23T12:27:17.978Z
Learning: Sensitive data (such as secrets and credentials) must be stored in environment variables, not in code or version control.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/environment-variables.mdc:0-0
Timestamp: 2025-07-03T12:02:45.107Z
Learning: Applies to apps/web/env.ts : For client-side environment variables, prefix them with `NEXT_PUBLIC_` and add them to both the `client` and `experimental__runtimeEnv` sections in `apps/web/env.ts`
Learnt from: CR
PR: elie222/inbox-zero#0
File: apps/web/CLAUDE.md:0-0
Timestamp: 2025-07-03T12:02:16.137Z
Learning: Applies to apps/web/**/{.env.example,env.ts} : Client-side environment variables must be prefixed with `NEXT_PUBLIC_`
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/environment-variables.mdc:0-0
Timestamp: 2025-07-03T12:02:45.107Z
Learning: Applies to apps/web/.env.example : Add new environment variables to `.env.example` with an example value
Learnt from: CR
PR: elie222/inbox-zero#0
File: apps/web/CLAUDE.md:0-0
Timestamp: 2025-07-03T12:02:16.137Z
Learning: Applies to apps/web/**/{.env.example,env.ts,turbo.json} : Add environment variables to `.env.example`, `env.ts`, and `turbo.json`
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/environment-variables.mdc:0-0
Timestamp: 2025-07-03T12:02:45.107Z
Learning: Applies to turbo.json : Add all new environment variables to the `env` array under the `build` task in `turbo.json`
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/environment-variables.mdc:0-0
Timestamp: 2025-07-03T12:02:45.107Z
Learning: Applies to apps/web/env.ts : For server-only environment variables, add them to the `server` section in `apps/web/env.ts`
apps/web/utils/outlook/filter.ts (2)
Learnt from: elie222
PR: elie222/inbox-zero#537
File: apps/web/app/api/user/stats/newsletters/route.ts:235-239
Timestamp: 2025-07-08T13:14:03.250Z
Learning: The user prefers proper TypeScript error type checking (using `error instanceof Error`) over type assertions with `as any` for better type safety and code quality.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/llm.mdc:0-0
Timestamp: 2025-06-23T12:26:36.694Z
Learning: Use TypeScript types for all parameters and return values, and define clear interfaces for complex input and output structures to ensure type safety.
apps/web/utils/encryption.test.ts (6)
Learnt from: CR
PR: elie222/inbox-zero#0
File: apps/web/CLAUDE.md:0-0
Timestamp: 2025-07-03T12:02:16.137Z
Learning: Applies to apps/web/**/{.env.example,env.ts,turbo.json} : Add environment variables to `.env.example`, `env.ts`, and `turbo.json`
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/llm-test.mdc:0-0
Timestamp: 2025-06-23T12:26:27.693Z
Learning: When writing tests for LLM-related functionality in TypeScript (e.g., in 'apps/web/__tests__/*.test.ts'), always create helper functions for common test data to ensure consistency and reduce duplication.
Learnt from: CR
PR: elie222/inbox-zero#0
File: apps/web/CLAUDE.md:0-0
Timestamp: 2025-07-03T12:02:16.137Z
Learning: Applies to apps/web/**/{.env.example,env.ts} : Client-side environment variables must be prefixed with `NEXT_PUBLIC_`
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/environment-variables.mdc:0-0
Timestamp: 2025-07-03T12:02:45.107Z
Learning: Applies to apps/web/env.ts : For client-side environment variables, prefix them with `NEXT_PUBLIC_` and add them to both the `client` and `experimental__runtimeEnv` sections in `apps/web/env.ts`
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-06-23T12:27:30.570Z
Learning: When mocking Prisma in Vitest, import the Prisma mock from '@/utils/__mocks__/prisma', mock '@/utils/prisma', and clear all mocks in a beforeEach hook to ensure test isolation.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/environment-variables.mdc:0-0
Timestamp: 2025-07-03T12:02:45.107Z
Learning: Applies to apps/web/.env.example : Add new environment variables to `.env.example` with an example value
.github/workflows/test.yml (2)
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: Do not hardcode secrets directly in code for cron endpoints; secrets should be managed via environment variables (e.g., CRON_SECRET) and not as plain strings in the source code.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-06-23T12:27:17.978Z
Learning: Sensitive data (such as secrets and credentials) must be stored in environment variables, not in code or version control.
apps/web/utils/encryption.ts (6)
Learnt from: CR
PR: elie222/inbox-zero#0
File: apps/web/CLAUDE.md:0-0
Timestamp: 2025-07-03T12:02:16.137Z
Learning: Applies to apps/web/**/{.env.example,env.ts,turbo.json} : Add environment variables to `.env.example`, `env.ts`, and `turbo.json`
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: Do not hardcode secrets directly in code for cron endpoints; secrets should be managed via environment variables (e.g., CRON_SECRET) and not as plain strings in the source code.
Learnt from: CR
PR: elie222/inbox-zero#0
File: apps/web/CLAUDE.md:0-0
Timestamp: 2025-07-03T12:02:16.137Z
Learning: Applies to apps/web/**/{.env.example,env.ts} : Client-side environment variables must be prefixed with `NEXT_PUBLIC_`
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/environment-variables.mdc:0-0
Timestamp: 2025-07-03T12:02:45.107Z
Learning: Applies to apps/web/env.ts : For client-side environment variables, prefix them with `NEXT_PUBLIC_` and add them to both the `client` and `experimental__runtimeEnv` sections in `apps/web/env.ts`
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-06-23T12:27:17.978Z
Learning: Sensitive data (such as secrets and credentials) must be stored in environment variables, not in code or version control.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/environment-variables.mdc:0-0
Timestamp: 2025-07-03T12:02:45.107Z
Learning: Applies to apps/web/env.ts : For server-only environment variables, add them to the `server` section in `apps/web/env.ts`
apps/web/components/GroupedTable.tsx (5)
Learnt from: elie222
PR: elie222/inbox-zero#537
File: apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx:30-34
Timestamp: 2025-07-08T13:14:07.449Z
Learning: The clean onboarding page in apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx is intentionally Gmail-specific and should show an error for non-Google email accounts rather than attempting to support multiple providers.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Always use wrapper functions from the utils folder (e.g., apps/web/utils/gmail/message.ts) to interact with provider APIs, ensuring maintainability and easier future provider support.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Keep provider-specific implementation details isolated within their respective utility directories (e.g., apps/web/utils/gmail/ for Gmail), which allows for easier addition of new providers in the future.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Never call provider APIs (such as Gmail) directly from routes or components; always use abstraction layers provided by utility wrapper functions.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-06-23T12:27:17.978Z
Learning: In Next.js/TypeScript API routes, always use authentication middleware (withAuth for user-level, withEmailAccount for account-level) to protect endpoints that handle user data.
apps/web/store/archive-sender-queue.ts (2)
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Always use wrapper functions from the utils folder (e.g., apps/web/utils/gmail/message.ts) to interact with provider APIs, ensuring maintainability and easier future provider support.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Keep provider-specific implementation details isolated within their respective utility directories (e.g., apps/web/utils/gmail/ for Gmail), which allows for easier addition of new providers in the future.
apps/web/app/(app)/[emailAccountId]/assistant/ProcessRules.tsx (9)
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/data-fetching.mdc:0-0
Timestamp: 2025-07-03T12:02:38.024Z
Learning: For mutating data, use Next.js server actions
Learnt from: CR
PR: elie222/inbox-zero#0
File: apps/web/CLAUDE.md:0-0
Timestamp: 2025-07-03T12:02:16.137Z
Learning: Applies to apps/web/**/*.tsx : Prefer functional components with hooks
Learnt from: elie222
PR: elie222/inbox-zero#537
File: apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx:30-34
Timestamp: 2025-07-08T13:14:07.449Z
Learning: The clean onboarding page in apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx is intentionally Gmail-specific and should show an error for non-Google email accounts rather than attempting to support multiple providers.
Learnt from: CR
PR: elie222/inbox-zero#0
File: apps/web/CLAUDE.md:0-0
Timestamp: 2025-07-03T12:02:16.137Z
Learning: Applies to apps/web/**/*.tsx : Follow consistent naming conventions (PascalCase for components)
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/hooks.mdc:0-0
Timestamp: 2025-06-23T12:26:16.769Z
Learning: For data fetching in custom React hooks, prefer using the useSWR hook. The custom hook should typically wrap useSWR, handle the API endpoint URL, and return the data, loading state, error state, and potentially the mutate function from SWR.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/ui-components.mdc:0-0
Timestamp: 2025-06-23T12:27:33.499Z
Learning: When fetching data from an API in a Next.js React application, use the `swr` package for GET requests to the server. This provides built-in caching, revalidation, and error handling.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/project-structure.mdc:0-0
Timestamp: 2025-06-23T12:26:59.468Z
Learning: Use SWR for data fetching in deeply nested components in Next.js App Router projects to enable efficient client-side data fetching and caching.
Learnt from: elie222
PR: elie222/inbox-zero#485
File: apps/web/app/(landing)/login/page.tsx:41-43
Timestamp: 2025-06-05T09:49:12.168Z
Learning: In Next.js App Router, components that use the `useSearchParams` hook require a Suspense boundary to handle the asynchronous nature of search parameter access. The Suspense wrapper is necessary and should not be removed when a component uses useSearchParams.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/page-structure.mdc:0-0
Timestamp: 2025-06-23T12:26:47.630Z
Learning: In deeply nested React components within the Next.js app directory, use the SWR library to fetch data via API instead of loading data directly in the component.
apps/web/hooks/useLabels.ts (2)
Learnt from: CR
PR: elie222/inbox-zero#0
File: apps/web/CLAUDE.md:0-0
Timestamp: 2025-07-03T12:02:16.137Z
Learning: Applies to apps/web/**/*.{ts,tsx} : Use TypeScript with strict null checks
Learnt from: CR
PR: elie222/inbox-zero#0
File: apps/web/CLAUDE.md:0-0
Timestamp: 2025-07-03T12:02:16.137Z
Learning: Applies to apps/web/**/types/**/*.{ts,d.ts} : Centralize types in dedicated type files when shared
apps/web/app/api/messages/attachment/route.ts (10)
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: In Next.js App Router, GET API route handlers should be wrapped with either `withAuth` or `withEmailAccount` middleware to ensure consistent error handling and authentication.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: When using `withAuth` or `withEmailAccount` middleware in GET API routes, explicit try/catch blocks are unnecessary because the middleware handles errors.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-06-23T12:27:17.978Z
Learning: In Next.js/TypeScript API routes, always use authentication middleware (withAuth for user-level, withEmailAccount for account-level) to protect endpoints that handle user data.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Always use wrapper functions from the utils folder (e.g., apps/web/utils/gmail/message.ts) to interact with provider APIs, ensuring maintainability and easier future provider support.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: In Next.js API routes under apps/web/app/api/, always use authentication middleware such as withAuth or withEmailAccount, or ensure custom authentication logic is present if using withError.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: Responses from GET API routes in Next.js should be returned using `NextResponse.json()` for consistency and proper response formatting.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: Prisma should be used as the ORM for all database queries within GET API routes in Next.js.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: All Prisma queries in API routes must be scoped to the current user or account by including emailAccountId or userId in the WHERE clause to prevent unauthorized data access (IDOR vulnerabilities).
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/data-fetching.mdc:0-0
Timestamp: 2025-07-03T12:02:38.024Z
Learning: Applies to **/*.tsx : For API GET requests to server, use the `swr` package
Learnt from: elie222
PR: elie222/inbox-zero#537
File: apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx:30-34
Timestamp: 2025-07-08T13:14:07.449Z
Learning: The clean onboarding page in apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx is intentionally Gmail-specific and should show an error for non-Google email accounts rather than attempting to support multiple providers.
apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx (12)
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/prisma.mdc:0-0
Timestamp: 2025-06-23T12:26:53.882Z
Learning: In this project, Prisma should be imported using 'import prisma from "@/utils/prisma";' in TypeScript files.
Learnt from: elie222
PR: elie222/inbox-zero#537
File: apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx:30-34
Timestamp: 2025-07-08T13:14:07.449Z
Learning: The clean onboarding page in apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx is intentionally Gmail-specific and should show an error for non-Google email accounts rather than attempting to support multiple providers.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-06-23T12:27:30.570Z
Learning: When mocking Prisma in Vitest, import the Prisma mock from '@/utils/__mocks__/prisma', mock '@/utils/prisma', and clear all mocks in a beforeEach hook to ensure test isolation.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/data-fetching.mdc:0-0
Timestamp: 2025-07-03T12:02:38.024Z
Learning: For mutating data, use Next.js server actions
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: Prisma should be used as the ORM for all database queries within GET API routes in Next.js.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-06-23T12:27:17.978Z
Learning: In Next.js/TypeScript API routes, always use authentication middleware (withAuth for user-level, withEmailAccount for account-level) to protect endpoints that handle user data.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/prisma.mdc:0-0
Timestamp: 2025-06-23T12:26:53.882Z
Learning: The project uses PostgreSQL as the database with Prisma.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/form-handling.mdc:0-0
Timestamp: 2025-07-03T12:02:53.001Z
Learning: Applies to **/*.tsx : Validate form inputs before submission
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: All Prisma queries in API routes must be scoped to the current user or account by including emailAccountId or userId in the WHERE clause to prevent unauthorized data access (IDOR vulnerabilities).
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Never call provider APIs (such as Gmail) directly from routes or components; always use abstraction layers provided by utility wrapper functions.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: In Next.js App Router, GET API route handlers should be wrapped with either `withAuth` or `withEmailAccount` middleware to ensure consistent error handling and authentication.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Always use wrapper functions from the utils folder (e.g., apps/web/utils/gmail/message.ts) to interact with provider APIs, ensuring maintainability and easier future provider support.
apps/web/package.json (3)
Learnt from: CR
PR: elie222/inbox-zero#0
File: apps/web/CLAUDE.md:0-0
Timestamp: 2025-07-03T12:02:16.137Z
Learning: Applies to apps/web/**/types/**/*.{ts,d.ts} : Centralize types in dedicated type files when shared
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/prisma.mdc:0-0
Timestamp: 2025-06-23T12:26:53.882Z
Learning: In this project, Prisma should be imported using 'import prisma from "@/utils/prisma";' in TypeScript files.
Learnt from: CR
PR: elie222/inbox-zero#0
File: apps/web/CLAUDE.md:0-0
Timestamp: 2025-07-03T12:02:16.137Z
Learning: Applies to apps/web/**/*.tsx : Follow tailwindcss patterns with prettier-plugin-tailwindcss
turbo.json (2)
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/environment-variables.mdc:0-0
Timestamp: 2025-07-03T12:02:45.107Z
Learning: Applies to turbo.json : Add all new environment variables to the `env` array under the `build` task in `turbo.json`
Learnt from: CR
PR: elie222/inbox-zero#0
File: apps/web/CLAUDE.md:0-0
Timestamp: 2025-07-03T12:02:16.137Z
Learning: Applies to apps/web/**/{.env.example,env.ts,turbo.json} : Add environment variables to `.env.example`, `env.ts`, and `turbo.json`
apps/web/utils/outlook/trash.ts (2)
Learnt from: elie222
PR: elie222/inbox-zero#537
File: apps/web/app/api/user/stats/newsletters/route.ts:235-239
Timestamp: 2025-07-08T13:14:03.250Z
Learning: The user prefers proper TypeScript error type checking (using `error instanceof Error`) over type assertions with `as any` for better type safety and code quality.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/form-handling.mdc:0-0
Timestamp: 2025-07-03T12:02:53.001Z
Learning: Applies to **/*.{ts,tsx} : Use descriptive error messages
apps/web/app/(landing)/login/LoginForm.tsx (1)
Learnt from: elie222
PR: elie222/inbox-zero#537
File: apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx:30-34
Timestamp: 2025-07-08T13:14:07.449Z
Learning: The clean onboarding page in apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx is intentionally Gmail-specific and should show an error for non-Google email accounts rather than attempting to support multiple providers.
apps/web/app/api/outlook/webhook/process-history.ts (6)
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Always use wrapper functions from the utils folder (e.g., apps/web/utils/gmail/message.ts) to interact with provider APIs, ensuring maintainability and easier future provider support.
Learnt from: elie222
PR: elie222/inbox-zero#537
File: apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx:30-34
Timestamp: 2025-07-08T13:14:07.449Z
Learning: The clean onboarding page in apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx is intentionally Gmail-specific and should show an error for non-Google email accounts rather than attempting to support multiple providers.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Never call provider APIs (such as Gmail) directly from routes or components; always use abstraction layers provided by utility wrapper functions.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Keep provider-specific implementation details isolated within their respective utility directories (e.g., apps/web/utils/gmail/ for Gmail), which allows for easier addition of new providers in the future.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/prisma.mdc:0-0
Timestamp: 2025-06-23T12:26:53.882Z
Learning: In this project, Prisma should be imported using 'import prisma from "@/utils/prisma";' in TypeScript files.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-06-23T12:27:17.978Z
Learning: In Next.js/TypeScript API routes, always use authentication middleware (withAuth for user-level, withEmailAccount for account-level) to protect endpoints that handle user data.
apps/web/utils/outlook/client.ts (2)
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/environment-variables.mdc:0-0
Timestamp: 2025-07-03T12:02:45.107Z
Learning: Applies to apps/web/env.ts : For client-side environment variables, prefix them with `NEXT_PUBLIC_` and add them to both the `client` and `experimental__runtimeEnv` sections in `apps/web/env.ts`
Learnt from: elie222
PR: elie222/inbox-zero#537
File: apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx:30-34
Timestamp: 2025-07-08T13:14:07.449Z
Learning: The clean onboarding page in apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx is intentionally Gmail-specific and should show an error for non-Google email accounts rather than attempting to support multiple providers.
apps/web/app/api/google/webhook/process-history.ts (6)
Learnt from: elie222
PR: elie222/inbox-zero#537
File: apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx:30-34
Timestamp: 2025-07-08T13:14:07.449Z
Learning: The clean onboarding page in apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx is intentionally Gmail-specific and should show an error for non-Google email accounts rather than attempting to support multiple providers.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Always use wrapper functions from the utils folder (e.g., apps/web/utils/gmail/message.ts) to interact with provider APIs, ensuring maintainability and easier future provider support.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Never call provider APIs (such as Gmail) directly from routes or components; always use abstraction layers provided by utility wrapper functions.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Keep provider-specific implementation details isolated within their respective utility directories (e.g., apps/web/utils/gmail/ for Gmail), which allows for easier addition of new providers in the future.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/prisma.mdc:0-0
Timestamp: 2025-06-23T12:26:53.882Z
Learning: In this project, Prisma should be imported using 'import prisma from "@/utils/prisma";' in TypeScript files.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: In Next.js API routes under apps/web/app/api/, always use authentication middleware such as withAuth or withEmailAccount, or ensure custom authentication logic is present if using withError.
apps/web/components/EmailMessageCell.tsx (5)
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Always use wrapper functions from the utils folder (e.g., apps/web/utils/gmail/message.ts) to interact with provider APIs, ensuring maintainability and easier future provider support.
Learnt from: elie222
PR: elie222/inbox-zero#537
File: apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx:30-34
Timestamp: 2025-07-08T13:14:07.449Z
Learning: The clean onboarding page in apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx is intentionally Gmail-specific and should show an error for non-Google email accounts rather than attempting to support multiple providers.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/project-structure.mdc:0-0
Timestamp: 2025-06-23T12:26:59.468Z
Learning: For components with onClick handlers in Next.js App Router, ensure they are client components by including the 'use client' directive at the top of the file.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/page-structure.mdc:0-0
Timestamp: 2025-06-23T12:26:47.630Z
Learning: In deeply nested React components within the Next.js app directory, use the SWR library to fetch data via API instead of loading data directly in the component.
Learnt from: aryanprince
PR: elie222/inbox-zero#210
File: apps/web/app/(app)/stats/NewsletterModal.tsx:2-4
Timestamp: 2024-08-23T11:37:26.779Z
Learning: `MoreDropdown` is a React component and `useUnsubscribeButton` is a custom React hook, and they should not be imported using `import type`.
apps/web/utils/auth.ts (2)
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Always use wrapper functions from the utils folder (e.g., apps/web/utils/gmail/message.ts) to interact with provider APIs, ensuring maintainability and easier future provider support.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Keep provider-specific implementation details isolated within their respective utility directories (e.g., apps/web/utils/gmail/ for Gmail), which allows for easier addition of new providers in the future.
README.md (8)
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: Do not hardcode secrets directly in code for cron endpoints; secrets should be managed via environment variables (e.g., CRON_SECRET) and not as plain strings in the source code.
Learnt from: elie222
PR: elie222/inbox-zero#537
File: apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx:30-34
Timestamp: 2025-07-08T13:14:07.449Z
Learning: The clean onboarding page in apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx is intentionally Gmail-specific and should show an error for non-Google email accounts rather than attempting to support multiple providers.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/environment-variables.mdc:0-0
Timestamp: 2025-07-03T12:02:45.107Z
Learning: Applies to apps/web/env.ts : For client-side environment variables, prefix them with `NEXT_PUBLIC_` and add them to both the `client` and `experimental__runtimeEnv` sections in `apps/web/env.ts`
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-06-23T12:27:17.978Z
Learning: Sensitive data (such as secrets and credentials) must be stored in environment variables, not in code or version control.
Learnt from: CR
PR: elie222/inbox-zero#0
File: apps/web/CLAUDE.md:0-0
Timestamp: 2025-07-03T12:02:16.137Z
Learning: Applies to apps/web/**/{.env.example,env.ts} : Client-side environment variables must be prefixed with `NEXT_PUBLIC_`
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/environment-variables.mdc:0-0
Timestamp: 2025-07-03T12:02:45.107Z
Learning: Applies to apps/web/.env.example : Add new environment variables to `.env.example` with an example value
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: Cron endpoints in API routes must be protected with secret validation middleware such as hasCronSecret or hasPostCronSecret to prevent unauthorized access.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-06-23T12:27:17.978Z
Learning: Cron endpoints must use withError middleware and validate requests with strong secrets (hasCronSecret/hasPostCronSecret); never use weak or predictable secrets.
apps/web/utils/actions/admin.ts (10)
Learnt from: elie222
PR: elie222/inbox-zero#537
File: apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx:30-34
Timestamp: 2025-07-08T13:14:07.449Z
Learning: The clean onboarding page in apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx is intentionally Gmail-specific and should show an error for non-Google email accounts rather than attempting to support multiple providers.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Keep provider-specific implementation details isolated within their respective utility directories (e.g., apps/web/utils/gmail/ for Gmail), which allows for easier addition of new providers in the future.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Always use wrapper functions from the utils folder (e.g., apps/web/utils/gmail/message.ts) to interact with provider APIs, ensuring maintainability and easier future provider support.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Never call provider APIs (such as Gmail) directly from routes or components; always use abstraction layers provided by utility wrapper functions.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/logging.mdc:0-0
Timestamp: 2025-06-23T12:26:43.177Z
Learning: In TypeScript backend code, use the `createScopedLogger` function from `@/utils/logger` to perform logging. Typically, instantiate the logger at the top of the file with a relevant scope string.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/llm.mdc:0-0
Timestamp: 2025-06-23T12:26:36.694Z
Learning: When implementing LLM-related functions in TypeScript, follow a standard structure: create a scoped logger, define a Zod schema for output validation, perform early input validation and returns, separate system and user prompts, log inputs and outputs, call the LLM with proper configuration, and return the validated result.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/server-actions.mdc:0-0
Timestamp: 2025-06-23T12:27:23.938Z
Learning: In Next.js projects, server actions should be implemented using the next-safe-action library to ensure type safety, input validation, context management, and centralized error handling.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: All Prisma queries in API routes must be scoped to the current user or account by including emailAccountId or userId in the WHERE clause to prevent unauthorized data access (IDOR vulnerabilities).
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-06-23T12:27:17.978Z
Learning: All findUnique/findFirst/findMany Prisma queries in API routes must include ownership filters to ensure only the authenticated user's data is accessed.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: When returning data from Prisma queries in API routes, use the select option to limit the fields returned to only those necessary for the client.
apps/web/app/api/labels/route.ts (15)
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: In Next.js App Router, GET API route handlers should be wrapped with either `withAuth` or `withEmailAccount` middleware to ensure consistent error handling and authentication.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: When using `withAuth` or `withEmailAccount` middleware in GET API routes, explicit try/catch blocks are unnecessary because the middleware handles errors.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-06-23T12:27:17.978Z
Learning: In Next.js/TypeScript API routes, always use authentication middleware (withAuth for user-level, withEmailAccount for account-level) to protect endpoints that handle user data.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: In Next.js API routes under apps/web/app/api/, always use authentication middleware such as withAuth or withEmailAccount, or ensure custom authentication logic is present if using withError.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Never call provider APIs (such as Gmail) directly from routes or components; always use abstraction layers provided by utility wrapper functions.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/data-fetching.mdc:0-0
Timestamp: 2025-07-03T12:02:38.024Z
Learning: Applies to **/*.tsx : For API GET requests to server, use the `swr` package
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/prisma.mdc:0-0
Timestamp: 2025-06-23T12:26:53.882Z
Learning: In this project, Prisma should be imported using 'import prisma from "@/utils/prisma";' in TypeScript files.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: Prisma should be used as the ORM for all database queries within GET API routes in Next.js.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/data-fetching.mdc:0-0
Timestamp: 2025-07-03T12:02:38.024Z
Learning: For mutating data, use Next.js server actions
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: Responses from GET API routes in Next.js should be returned using `NextResponse.json()` for consistency and proper response formatting.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/server-actions.mdc:0-0
Timestamp: 2025-06-23T12:27:23.938Z
Learning: In Next.js projects, server actions should be implemented using the next-safe-action library to ensure type safety, input validation, context management, and centralized error handling.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/prisma.mdc:0-0
Timestamp: 2025-06-23T12:26:53.882Z
Learning: The project uses PostgreSQL as the database with Prisma.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: All Prisma queries in API routes must be scoped to the current user or account by including emailAccountId or userId in the WHERE clause to prevent unauthorized data access (IDOR vulnerabilities).
Learnt from: elie222
PR: elie222/inbox-zero#537
File: apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx:30-34
Timestamp: 2025-07-08T13:14:07.449Z
Learning: The clean onboarding page in apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx is intentionally Gmail-specific and should show an error for non-Google email accounts rather than attempting to support multiple providers.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Always use wrapper functions from the utils folder (e.g., apps/web/utils/gmail/message.ts) to interact with provider APIs, ensuring maintainability and easier future provider support.
apps/web/env.ts (8)
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/environment-variables.mdc:0-0
Timestamp: 2025-07-03T12:02:45.107Z
Learning: Applies to apps/web/env.ts : For server-only environment variables, add them to the `server` section in `apps/web/env.ts`
Learnt from: CR
PR: elie222/inbox-zero#0
File: apps/web/CLAUDE.md:0-0
Timestamp: 2025-07-03T12:02:16.137Z
Learning: Applies to apps/web/**/{.env.example,env.ts,turbo.json} : Add environment variables to `.env.example`, `env.ts`, and `turbo.json`
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/environment-variables.mdc:0-0
Timestamp: 2025-07-03T12:02:45.107Z
Learning: Applies to apps/web/env.ts : For client-side environment variables, prefix them with `NEXT_PUBLIC_` and add them to both the `client` and `experimental__runtimeEnv` sections in `apps/web/env.ts`
Learnt from: CR
PR: elie222/inbox-zero#0
File: apps/web/CLAUDE.md:0-0
Timestamp: 2025-07-03T12:02:16.137Z
Learning: Applies to apps/web/**/{.env.example,env.ts} : Client-side environment variables must be prefixed with `NEXT_PUBLIC_`
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/environment-variables.mdc:0-0
Timestamp: 2025-07-03T12:02:45.107Z
Learning: Applies to apps/web/.env.example : Add new environment variables to `.env.example` with an example value
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-06-23T12:27:17.978Z
Learning: Sensitive data (such as secrets and credentials) must be stored in environment variables, not in code or version control.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/environment-variables.mdc:0-0
Timestamp: 2025-07-03T12:02:45.107Z
Learning: Applies to turbo.json : Add all new environment variables to the `env` array under the `build` task in `turbo.json`
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: Do not hardcode secrets directly in code for cron endpoints; secrets should be managed via environment variables (e.g., CRON_SECRET) and not as plain strings in the source code.
apps/web/app/api/labels/create/route.ts (11)
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: In Next.js App Router, GET API route handlers should be wrapped with either `withAuth` or `withEmailAccount` middleware to ensure consistent error handling and authentication.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-06-23T12:27:17.978Z
Learning: In Next.js/TypeScript API routes, always use authentication middleware (withAuth for user-level, withEmailAccount for account-level) to protect endpoints that handle user data.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: In Next.js API routes under apps/web/app/api/, always use authentication middleware such as withAuth or withEmailAccount, or ensure custom authentication logic is present if using withError.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: When using `withAuth` or `withEmailAccount` middleware in GET API routes, explicit try/catch blocks are unnecessary because the middleware handles errors.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Never call provider APIs (such as Gmail) directly from routes or components; always use abstraction layers provided by utility wrapper functions.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Always use wrapper functions from the utils folder (e.g., apps/web/utils/gmail/message.ts) to interact with provider APIs, ensuring maintainability and easier future provider support.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/data-fetching.mdc:0-0
Timestamp: 2025-07-03T12:02:38.024Z
Learning: For mutating data, use Next.js server actions
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: Responses from GET API routes in Next.js should be returned using `NextResponse.json()` for consistency and proper response formatting.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: Prisma should be used as the ORM for all database queries within GET API routes in Next.js.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/prisma.mdc:0-0
Timestamp: 2025-06-23T12:26:53.882Z
Learning: The project uses PostgreSQL as the database with Prisma.
Learnt from: elie222
PR: elie222/inbox-zero#537
File: apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx:30-34
Timestamp: 2025-07-08T13:14:07.449Z
Learning: The clean onboarding page in apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx is intentionally Gmail-specific and should show an error for non-Google email accounts rather than attempting to support multiple providers.
apps/web/app/api/threads/basic/route.ts (11)
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: In Next.js App Router, GET API route handlers should be wrapped with either `withAuth` or `withEmailAccount` middleware to ensure consistent error handling and authentication.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-06-23T12:27:17.978Z
Learning: In Next.js/TypeScript API routes, always use authentication middleware (withAuth for user-level, withEmailAccount for account-level) to protect endpoints that handle user data.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: When using `withAuth` or `withEmailAccount` middleware in GET API routes, explicit try/catch blocks are unnecessary because the middleware handles errors.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: In Next.js API routes under apps/web/app/api/, always use authentication middleware such as withAuth or withEmailAccount, or ensure custom authentication logic is present if using withError.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Always use wrapper functions from the utils folder (e.g., apps/web/utils/gmail/message.ts) to interact with provider APIs, ensuring maintainability and easier future provider support.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Never call provider APIs (such as Gmail) directly from routes or components; always use abstraction layers provided by utility wrapper functions.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: Responses from GET API routes in Next.js should be returned using `NextResponse.json()` for consistency and proper response formatting.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/data-fetching.mdc:0-0
Timestamp: 2025-07-03T12:02:38.024Z
Learning: Applies to **/*.tsx : For API GET requests to server, use the `swr` package
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: Response types for GET API routes in Next.js can be inferred and exported using `Awaited<ReturnType<typeof getData>>`, eliminating the need for manual type definitions.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: Prisma should be used as the ORM for all database queries within GET API routes in Next.js.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/ui-components.mdc:0-0
Timestamp: 2025-06-23T12:27:33.499Z
Learning: When fetching data from an API in a Next.js React application, use the `swr` package for GET requests to the server. This provides built-in caching, revalidation, and error handling.
apps/web/app/api/threads/[id]/route.ts (13)
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: In Next.js App Router, GET API route handlers should be wrapped with either `withAuth` or `withEmailAccount` middleware to ensure consistent error handling and authentication.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: When using `withAuth` or `withEmailAccount` middleware in GET API routes, explicit try/catch blocks are unnecessary because the middleware handles errors.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Never call provider APIs (such as Gmail) directly from routes or components; always use abstraction layers provided by utility wrapper functions.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Always use wrapper functions from the utils folder (e.g., apps/web/utils/gmail/message.ts) to interact with provider APIs, ensuring maintainability and easier future provider support.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-06-23T12:27:17.978Z
Learning: In Next.js/TypeScript API routes, always use authentication middleware (withAuth for user-level, withEmailAccount for account-level) to protect endpoints that handle user data.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Keep provider-specific implementation details isolated within their respective utility directories (e.g., apps/web/utils/gmail/ for Gmail), which allows for easier addition of new providers in the future.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: In Next.js API routes under apps/web/app/api/, always use authentication middleware such as withAuth or withEmailAccount, or ensure custom authentication logic is present if using withError.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/prisma.mdc:0-0
Timestamp: 2025-06-23T12:26:53.882Z
Learning: In this project, Prisma should be imported using 'import prisma from "@/utils/prisma";' in TypeScript files.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/form-handling.mdc:0-0
Timestamp: 2025-07-03T12:02:53.001Z
Learning: Applies to **/*.tsx : Use React Hook Form with Zod for validation
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/data-fetching.mdc:0-0
Timestamp: 2025-07-03T12:02:38.024Z
Learning: For mutating data, use Next.js server actions
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/prisma.mdc:0-0
Timestamp: 2025-06-23T12:26:53.882Z
Learning: The project uses PostgreSQL as the database with Prisma.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: Prisma should be used as the ORM for all database queries within GET API routes in Next.js.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: All Prisma queries in API routes must be scoped to the current user or account by including emailAccountId or userId in the WHERE clause to prevent unauthorized data access (IDOR vulnerabilities).
apps/web/app/api/threads/batch/route.ts (13)
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: In Next.js App Router, GET API route handlers should be wrapped with either `withAuth` or `withEmailAccount` middleware to ensure consistent error handling and authentication.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: When using `withAuth` or `withEmailAccount` middleware in GET API routes, explicit try/catch blocks are unnecessary because the middleware handles errors.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-06-23T12:27:17.978Z
Learning: In Next.js/TypeScript API routes, always use authentication middleware (withAuth for user-level, withEmailAccount for account-level) to protect endpoints that handle user data.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Always use wrapper functions from the utils folder (e.g., apps/web/utils/gmail/message.ts) to interact with provider APIs, ensuring maintainability and easier future provider support.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: In Next.js API routes under apps/web/app/api/, always use authentication middleware such as withAuth or withEmailAccount, or ensure custom authentication logic is present if using withError.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Never call provider APIs (such as Gmail) directly from routes or components; always use abstraction layers provided by utility wrapper functions.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/data-fetching.mdc:0-0
Timestamp: 2025-07-03T12:02:38.024Z
Learning: Applies to **/*.tsx : For API GET requests to server, use the `swr` package
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: Prisma should be used as the ORM for all database queries within GET API routes in Next.js.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/data-fetching.mdc:0-0
Timestamp: 2025-07-03T12:02:38.024Z
Learning: For mutating data, use Next.js server actions
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: All Prisma queries in API routes must be scoped to the current user or account by including emailAccountId or userId in the WHERE clause to prevent unauthorized data access (IDOR vulnerabilities).
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: Responses from GET API routes in Next.js should be returned using `NextResponse.json()` for consistency and proper response formatting.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: Response types for GET API routes in Next.js can be inferred and exported using `Awaited<ReturnType<typeof getData>>`, eliminating the need for manual type definitions.
Learnt from: elie222
PR: elie222/inbox-zero#537
File: apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx:30-34
Timestamp: 2025-07-08T13:14:07.449Z
Learning: The clean onboarding page in apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx is intentionally Gmail-specific and should show an error for non-Google email accounts rather than attempting to support multiple providers.
apps/web/app/api/user/stats/newsletters/route.ts (14)
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Always use wrapper functions from the utils folder (e.g., apps/web/utils/gmail/message.ts) to interact with provider APIs, ensuring maintainability and easier future provider support.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: In Next.js App Router, GET API route handlers should be wrapped with either `withAuth` or `withEmailAccount` middleware to ensure consistent error handling and authentication.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Never call provider APIs (such as Gmail) directly from routes or components; always use abstraction layers provided by utility wrapper functions.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Keep provider-specific implementation details isolated within their respective utility directories (e.g., apps/web/utils/gmail/ for Gmail), which allows for easier addition of new providers in the future.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: When using `withAuth` or `withEmailAccount` middleware in GET API routes, explicit try/catch blocks are unnecessary because the middleware handles errors.
Learnt from: elie222
PR: elie222/inbox-zero#537
File: apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx:30-34
Timestamp: 2025-07-08T13:14:07.449Z
Learning: The clean onboarding page in apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx is intentionally Gmail-specific and should show an error for non-Google email accounts rather than attempting to support multiple providers.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-06-23T12:27:17.978Z
Learning: In Next.js/TypeScript API routes, always use authentication middleware (withAuth for user-level, withEmailAccount for account-level) to protect endpoints that handle user data.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: In Next.js API routes under apps/web/app/api/, always use authentication middleware such as withAuth or withEmailAccount, or ensure custom authentication logic is present if using withError.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: Prisma should be used as the ORM for all database queries within GET API routes in Next.js.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/prisma.mdc:0-0
Timestamp: 2025-06-23T12:26:53.882Z
Learning: The project uses PostgreSQL as the database with Prisma.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/data-fetching.mdc:0-0
Timestamp: 2025-07-03T12:02:38.024Z
Learning: For mutating data, use Next.js server actions
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/prisma.mdc:0-0
Timestamp: 2025-06-23T12:26:53.882Z
Learning: In this project, Prisma should be imported using 'import prisma from "@/utils/prisma";' in TypeScript files.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/ui-components.mdc:0-0
Timestamp: 2025-06-23T12:27:33.499Z
Learning: When fetching data from an API in a Next.js React application, use the `swr` package for GET requests to the server. This provides built-in caching, revalidation, and error handling.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: When returning data from Prisma queries in API routes, use the select option to limit the fields returned to only those necessary for the client.
apps/web/utils/user/delete.ts (7)
Learnt from: elie222
PR: elie222/inbox-zero#537
File: apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx:30-34
Timestamp: 2025-07-08T13:14:07.449Z
Learning: The clean onboarding page in apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx is intentionally Gmail-specific and should show an error for non-Google email accounts rather than attempting to support multiple providers.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Always use wrapper functions from the utils folder (e.g., apps/web/utils/gmail/message.ts) to interact with provider APIs, ensuring maintainability and easier future provider support.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Keep provider-specific implementation details isolated within their respective utility directories (e.g., apps/web/utils/gmail/ for Gmail), which allows for easier addition of new providers in the future.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Never call provider APIs (such as Gmail) directly from routes or components; always use abstraction layers provided by utility wrapper functions.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: All Prisma queries in API routes must be scoped to the current user or account by including emailAccountId or userId in the WHERE clause to prevent unauthorized data access (IDOR vulnerabilities).
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-06-23T12:27:17.978Z
Learning: All findUnique/findFirst/findMany Prisma queries in API routes must include ownership filters to ensure only the authenticated user's data is accessed.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: When returning data from Prisma queries in API routes, use the select option to limit the fields returned to only those necessary for the client.
apps/web/app/(app)/[emailAccountId]/assistant/ExecutedRulesTable.tsx (3)
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Always use wrapper functions from the utils folder (e.g., apps/web/utils/gmail/message.ts) to interact with provider APIs, ensuring maintainability and easier future provider support.
Learnt from: elie222
PR: elie222/inbox-zero#537
File: apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx:30-34
Timestamp: 2025-07-08T13:14:07.449Z
Learning: The clean onboarding page in apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx is intentionally Gmail-specific and should show an error for non-Google email accounts rather than attempting to support multiple providers.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Never call provider APIs (such as Gmail) directly from routes or components; always use abstraction layers provided by utility wrapper functions.
apps/web/app/(app)/[emailAccountId]/bulk-unsubscribe/hooks.ts (9)
Learnt from: aryanprince
PR: elie222/inbox-zero#210
File: apps/web/app/(app)/stats/NewsletterModal.tsx:2-4
Timestamp: 2024-08-23T11:37:26.779Z
Learning: `MoreDropdown` is a React component and `useUnsubscribeButton` is a custom React hook, and they should not be imported using `import type`.
Learnt from: elie222
PR: elie222/inbox-zero#537
File: apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx:30-34
Timestamp: 2025-07-08T13:14:07.449Z
Learning: The clean onboarding page in apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx is intentionally Gmail-specific and should show an error for non-Google email accounts rather than attempting to support multiple providers.
Learnt from: CR
PR: elie222/inbox-zero#0
File: apps/web/CLAUDE.md:0-0
Timestamp: 2025-07-03T12:02:16.137Z
Learning: Applies to apps/web/**/*.tsx : Prefer functional components with hooks
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/hooks.mdc:0-0
Timestamp: 2025-06-23T12:26:16.769Z
Learning: When fetching different data types, create dedicated hooks for each type (e.g., useAccounts, useLabels) rather than using generic hooks.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Always use wrapper functions from the utils folder (e.g., apps/web/utils/gmail/message.ts) to interact with provider APIs, ensuring maintainability and easier future provider support.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/posthog-feature-flags.mdc:0-0
Timestamp: 2025-06-23T12:26:51.119Z
Learning: Centralize all feature flag hooks in a single file (e.g., 'useFeatureFlags.ts') to ensure maintainability and discoverability.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/hooks.mdc:0-0
Timestamp: 2025-06-23T12:26:16.769Z
Learning: For data fetching in custom React hooks, prefer using the useSWR hook. The custom hook should typically wrap useSWR, handle the API endpoint URL, and return the data, loading state, error state, and potentially the mutate function from SWR.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Never call provider APIs (such as Gmail) directly from routes or components; always use abstraction layers provided by utility wrapper functions.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/data-fetching.mdc:0-0
Timestamp: 2025-07-03T12:02:38.024Z
Learning: For mutating data, use Next.js server actions
apps/web/app/api/messages/route.ts (13)
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Always use wrapper functions from the utils folder (e.g., apps/web/utils/gmail/message.ts) to interact with provider APIs, ensuring maintainability and easier future provider support.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: In Next.js App Router, GET API route handlers should be wrapped with either `withAuth` or `withEmailAccount` middleware to ensure consistent error handling and authentication.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-06-23T12:27:17.978Z
Learning: In Next.js/TypeScript API routes, always use authentication middleware (withAuth for user-level, withEmailAccount for account-level) to protect endpoints that handle user data.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Never call provider APIs (such as Gmail) directly from routes or components; always use abstraction layers provided by utility wrapper functions.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: When using `withAuth` or `withEmailAccount` middleware in GET API routes, explicit try/catch blocks are unnecessary because the middleware handles errors.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Keep provider-specific implementation details isolated within their respective utility directories (e.g., apps/web/utils/gmail/ for Gmail), which allows for easier addition of new providers in the future.
Learnt from: elie222
PR: elie222/inbox-zero#537
File: apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx:30-34
Timestamp: 2025-07-08T13:14:07.449Z
Learning: The clean onboarding page in apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx is intentionally Gmail-specific and should show an error for non-Google email accounts rather than attempting to support multiple providers.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: In Next.js API routes under apps/web/app/api/, always use authentication middleware such as withAuth or withEmailAccount, or ensure custom authentication logic is present if using withError.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: Prisma should be used as the ORM for all database queries within GET API routes in Next.js.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: Responses from GET API routes in Next.js should be returned using `NextResponse.json()` for consistency and proper response formatting.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/prisma.mdc:0-0
Timestamp: 2025-06-23T12:26:53.882Z
Learning: In this project, Prisma should be imported using 'import prisma from "@/utils/prisma";' in TypeScript files.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/data-fetching.mdc:0-0
Timestamp: 2025-07-03T12:02:38.024Z
Learning: For mutating data, use Next.js server actions
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: All Prisma queries in API routes must be scoped to the current user or account by including emailAccountId or userId in the WHERE clause to prevent unauthorized data access (IDOR vulnerabilities).
apps/web/app/api/watch/unwatch/route.ts (5)
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: In Next.js App Router, GET API route handlers should be wrapped with either `withAuth` or `withEmailAccount` middleware to ensure consistent error handling and authentication.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-06-23T12:27:17.978Z
Learning: In Next.js/TypeScript API routes, always use authentication middleware (withAuth for user-level, withEmailAccount for account-level) to protect endpoints that handle user data.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: In Next.js API routes under apps/web/app/api/, always use authentication middleware such as withAuth or withEmailAccount, or ensure custom authentication logic is present if using withError.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: When using `withAuth` or `withEmailAccount` middleware in GET API routes, explicit try/catch blocks are unnecessary because the middleware handles errors.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/data-fetching.mdc:0-0
Timestamp: 2025-07-03T12:02:38.024Z
Learning: For mutating data, use Next.js server actions
apps/web/app/api/user/stats/newsletters/helpers.ts (3)
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Keep provider-specific implementation details isolated within their respective utility directories (e.g., apps/web/utils/gmail/ for Gmail), which allows for easier addition of new providers in the future.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Always use wrapper functions from the utils folder (e.g., apps/web/utils/gmail/message.ts) to interact with provider APIs, ensuring maintainability and easier future provider support.
Learnt from: elie222
PR: elie222/inbox-zero#537
File: apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx:30-34
Timestamp: 2025-07-08T13:14:07.449Z
Learning: The clean onboarding page in apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx is intentionally Gmail-specific and should show an error for non-Google email accounts rather than attempting to support multiple providers.
apps/web/app/api/watch/route.ts (11)
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: In Next.js App Router, GET API route handlers should be wrapped with either `withAuth` or `withEmailAccount` middleware to ensure consistent error handling and authentication.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: In Next.js API routes under apps/web/app/api/, always use authentication middleware such as withAuth or withEmailAccount, or ensure custom authentication logic is present if using withError.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-06-23T12:27:17.978Z
Learning: In Next.js/TypeScript API routes, always use authentication middleware (withAuth for user-level, withEmailAccount for account-level) to protect endpoints that handle user data.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: When using `withAuth` or `withEmailAccount` middleware in GET API routes, explicit try/catch blocks are unnecessary because the middleware handles errors.
Learnt from: elie222
PR: elie222/inbox-zero#537
File: apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx:30-34
Timestamp: 2025-07-08T13:14:07.449Z
Learning: The clean onboarding page in apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx is intentionally Gmail-specific and should show an error for non-Google email accounts rather than attempting to support multiple providers.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: Response types for GET API routes in Next.js can be inferred and exported using `Awaited<ReturnType<typeof getData>>`, eliminating the need for manual type definitions.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: All Prisma queries in API routes must be scoped to the current user or account by including emailAccountId or userId in the WHERE clause to prevent unauthorized data access (IDOR vulnerabilities).
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: Responses from GET API routes in Next.js should be returned using `NextResponse.json()` for consistency and proper response formatting.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/data-fetching.mdc:0-0
Timestamp: 2025-07-03T12:02:38.024Z
Learning: Applies to **/*.tsx : For API GET requests to server, use the `swr` package
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/ui-components.mdc:0-0
Timestamp: 2025-06-23T12:27:33.499Z
Learning: When fetching data from an API in a Next.js React application, use the `swr` package for GET requests to the server. This provides built-in caching, revalidation, and error handling.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/data-fetching.mdc:0-0
Timestamp: 2025-07-03T12:02:38.024Z
Learning: For mutating data, use Next.js server actions
apps/web/utils/middleware.ts (11)
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-06-23T12:27:17.978Z
Learning: In Next.js/TypeScript API routes, always use authentication middleware (withAuth for user-level, withEmailAccount for account-level) to protect endpoints that handle user data.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: In Next.js API routes under apps/web/app/api/, always use authentication middleware such as withAuth or withEmailAccount, or ensure custom authentication logic is present if using withError.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: In Next.js App Router, GET API route handlers should be wrapped with either `withAuth` or `withEmailAccount` middleware to ensure consistent error handling and authentication.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Always use wrapper functions from the utils folder (e.g., apps/web/utils/gmail/message.ts) to interact with provider APIs, ensuring maintainability and easier future provider support.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Keep provider-specific implementation details isolated within their respective utility directories (e.g., apps/web/utils/gmail/ for Gmail), which allows for easier addition of new providers in the future.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: When using `withAuth` or `withEmailAccount` middleware in GET API routes, explicit try/catch blocks are unnecessary because the middleware handles errors.
Learnt from: elie222
PR: elie222/inbox-zero#537
File: apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx:30-34
Timestamp: 2025-07-08T13:14:07.449Z
Learning: The clean onboarding page in apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx is intentionally Gmail-specific and should show an error for non-Google email accounts rather than attempting to support multiple providers.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/prisma.mdc:0-0
Timestamp: 2025-06-23T12:26:53.882Z
Learning: In this project, Prisma should be imported using 'import prisma from "@/utils/prisma";' in TypeScript files.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Never call provider APIs (such as Gmail) directly from routes or components; always use abstraction layers provided by utility wrapper functions.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: All Prisma queries in API routes must be scoped to the current user or account by including emailAccountId or userId in the WHERE clause to prevent unauthorized data access (IDOR vulnerabilities).
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-06-23T12:27:30.570Z
Learning: When mocking Prisma in Vitest, import the Prisma mock from '@/utils/__mocks__/prisma', mock '@/utils/prisma', and clear all mocks in a beforeEach hook to ensure test isolation.
apps/web/providers/EmailProvider.tsx (4)
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Always use wrapper functions from the utils folder (e.g., apps/web/utils/gmail/message.ts) to interact with provider APIs, ensuring maintainability and easier future provider support.
Learnt from: elie222
PR: elie222/inbox-zero#537
File: apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx:30-34
Timestamp: 2025-07-08T13:14:07.449Z
Learning: The clean onboarding page in apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx is intentionally Gmail-specific and should show an error for non-Google email accounts rather than attempting to support multiple providers.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Keep provider-specific implementation details isolated within their respective utility directories (e.g., apps/web/utils/gmail/ for Gmail), which allows for easier addition of new providers in the future.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Never call provider APIs (such as Gmail) directly from routes or components; always use abstraction layers provided by utility wrapper functions.
apps/web/app/api/messages/batch/route.ts (9)
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Always use wrapper functions from the utils folder (e.g., apps/web/utils/gmail/message.ts) to interact with provider APIs, ensuring maintainability and easier future provider support.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: In Next.js App Router, GET API route handlers should be wrapped with either `withAuth` or `withEmailAccount` middleware to ensure consistent error handling and authentication.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: When using `withAuth` or `withEmailAccount` middleware in GET API routes, explicit try/catch blocks are unnecessary because the middleware handles errors.
Learnt from: elie222
PR: elie222/inbox-zero#537
File: apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx:30-34
Timestamp: 2025-07-08T13:14:07.449Z
Learning: The clean onboarding page in apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx is intentionally Gmail-specific and should show an error for non-Google email accounts rather than attempting to support multiple providers.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Keep provider-specific implementation details isolated within their respective utility directories (e.g., apps/web/utils/gmail/ for Gmail), which allows for easier addition of new providers in the future.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Never call provider APIs (such as Gmail) directly from routes or components; always use abstraction layers provided by utility wrapper functions.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-06-23T12:27:17.978Z
Learning: In Next.js/TypeScript API routes, always use authentication middleware (withAuth for user-level, withEmailAccount for account-level) to protect endpoints that handle user data.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: In Next.js API routes under apps/web/app/api/, always use authentication middleware such as withAuth or withEmailAccount, or ensure custom authentication logic is present if using withError.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: All Prisma queries in API routes must be scoped to the current user or account by including emailAccountId or userId in the WHERE clause to prevent unauthorized data access (IDOR vulnerabilities).
apps/web/utils/url.ts (3)
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Keep provider-specific implementation details isolated within their respective utility directories (e.g., apps/web/utils/gmail/ for Gmail), which allows for easier addition of new providers in the future.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Always use wrapper functions from the utils folder (e.g., apps/web/utils/gmail/message.ts) to interact with provider APIs, ensuring maintainability and easier future provider support.
Learnt from: elie222
PR: elie222/inbox-zero#537
File: apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx:30-34
Timestamp: 2025-07-08T13:14:07.449Z
Learning: The clean onboarding page in apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx is intentionally Gmail-specific and should show an error for non-Google email accounts rather than attempting to support multiple providers.
apps/web/app/api/threads/route.ts (11)
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: In Next.js App Router, GET API route handlers should be wrapped with either `withAuth` or `withEmailAccount` middleware to ensure consistent error handling and authentication.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-06-23T12:27:17.978Z
Learning: In Next.js/TypeScript API routes, always use authentication middleware (withAuth for user-level, withEmailAccount for account-level) to protect endpoints that handle user data.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: In Next.js API routes under apps/web/app/api/, always use authentication middleware such as withAuth or withEmailAccount, or ensure custom authentication logic is present if using withError.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: When using `withAuth` or `withEmailAccount` middleware in GET API routes, explicit try/catch blocks are unnecessary because the middleware handles errors.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Always use wrapper functions from the utils folder (e.g., apps/web/utils/gmail/message.ts) to interact with provider APIs, ensuring maintainability and easier future provider support.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Never call provider APIs (such as Gmail) directly from routes or components; always use abstraction layers provided by utility wrapper functions.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/data-fetching.mdc:0-0
Timestamp: 2025-07-03T12:02:38.024Z
Learning: Applies to **/*.tsx : For API GET requests to server, use the `swr` package
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: Responses from GET API routes in Next.js should be returned using `NextResponse.json()` for consistency and proper response formatting.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: All Prisma queries in API routes must be scoped to the current user or account by including emailAccountId or userId in the WHERE clause to prevent unauthorized data access (IDOR vulnerabilities).
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: Response types for GET API routes in Next.js can be inferred and exported using `Awaited<ReturnType<typeof getData>>`, eliminating the need for manual type definitions.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/ui-components.mdc:0-0
Timestamp: 2025-06-23T12:27:33.499Z
Learning: When fetching data from an API in a Next.js React application, use the `swr` package for GET requests to the server. This provides built-in caching, revalidation, and error handling.
apps/web/app/api/watch/all/route.ts (6)
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-06-23T12:27:17.978Z
Learning: In Next.js/TypeScript API routes, always use authentication middleware (withAuth for user-level, withEmailAccount for account-level) to protect endpoints that handle user data.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: Cron endpoints in API routes must be protected with secret validation middleware such as hasCronSecret or hasPostCronSecret to prevent unauthorized access.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: In Next.js App Router, GET API route handlers should be wrapped with either `withAuth` or `withEmailAccount` middleware to ensure consistent error handling and authentication.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: In Next.js API routes under apps/web/app/api/, always use authentication middleware such as withAuth or withEmailAccount, or ensure custom authentication logic is present if using withError.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-06-23T12:27:17.978Z
Learning: Cron endpoints must use withError middleware and validate requests with strong secrets (hasCronSecret/hasPostCronSecret); never use weak or predictable secrets.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: All Prisma queries in API routes must be scoped to the current user or account by including emailAccountId or userId in the WHERE clause to prevent unauthorized data access (IDOR vulnerabilities).
apps/web/utils/email/provider.ts (5)
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Keep provider-specific implementation details isolated within their respective utility directories (e.g., apps/web/utils/gmail/ for Gmail), which allows for easier addition of new providers in the future.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Always use wrapper functions from the utils folder (e.g., apps/web/utils/gmail/message.ts) to interact with provider APIs, ensuring maintainability and easier future provider support.
Learnt from: elie222
PR: elie222/inbox-zero#537
File: apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx:30-34
Timestamp: 2025-07-08T13:14:07.449Z
Learning: The clean onboarding page in apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx is intentionally Gmail-specific and should show an error for non-Google email accounts rather than attempting to support multiple providers.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Never call provider APIs (such as Gmail) directly from routes or components; always use abstraction layers provided by utility wrapper functions.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/logging.mdc:0-0
Timestamp: 2025-06-23T12:26:43.177Z
Learning: In TypeScript backend code, use the `createScopedLogger` function from `@/utils/logger` to perform logging. Typically, instantiate the logger at the top of the file with a relevant scope string.
apps/web/app/api/watch/controller.ts (5)
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Always use wrapper functions from the utils folder (e.g., apps/web/utils/gmail/message.ts) to interact with provider APIs, ensuring maintainability and easier future provider support.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Never call provider APIs (such as Gmail) directly from routes or components; always use abstraction layers provided by utility wrapper functions.
Learnt from: elie222
PR: elie222/inbox-zero#537
File: apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx:30-34
Timestamp: 2025-07-08T13:14:07.449Z
Learning: The clean onboarding page in apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx is intentionally Gmail-specific and should show an error for non-Google email accounts rather than attempting to support multiple providers.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: All Prisma queries in API routes must be scoped to the current user or account by including emailAccountId or userId in the WHERE clause to prevent unauthorized data access (IDOR vulnerabilities).
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Keep provider-specific implementation details isolated within their respective utility directories (e.g., apps/web/utils/gmail/ for Gmail), which allows for easier addition of new providers in the future.
🧬 Code Graph Analysis (19)
apps/web/app/(app)/[emailAccountId]/PermissionsCheck.tsx (1)
apps/web/providers/EmailAccountProvider.tsx (1)
useAccount(72-82)
apps/web/components/SideNav.tsx (1)
apps/web/providers/EmailAccountProvider.tsx (1)
useAccount(72-82)
apps/web/utils/encryption.ts (1)
apps/web/env.ts (1)
env(5-216)
apps/web/components/GroupedTable.tsx (1)
apps/web/providers/EmailAccountProvider.tsx (1)
useAccount(72-82)
apps/web/store/archive-sender-queue.ts (1)
apps/web/utils/types.ts (1)
isDefined(8-10)
apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx (1)
apps/web/utils/email/provider.ts (1)
createEmailProvider(1614-1629)
apps/web/utils/outlook/client.ts (1)
apps/web/env.ts (1)
env(5-216)
apps/web/components/EmailMessageCell.tsx (1)
apps/web/utils/url.ts (1)
getEmailUrlForMessage(60-70)
apps/web/utils/auth.ts (1)
apps/web/env.ts (1)
env(5-216)
apps/web/utils/actions/admin.ts (2)
apps/web/utils/error.ts (1)
SafeError(83-91)apps/web/utils/email/provider.ts (1)
createEmailProvider(1614-1629)
apps/web/app/api/labels/route.ts (5)
apps/web/app/api/messages/route.ts (1)
GET(86-102)apps/web/app/api/threads/basic/route.ts (1)
GET(16-40)apps/web/app/api/threads/[id]/route.ts (1)
GET(31-55)apps/web/app/api/watch/route.ts (1)
GET(12-92)apps/web/utils/middleware.ts (1)
withEmailProvider(258-262)
apps/web/app/api/threads/basic/route.ts (5)
apps/web/utils/logger.ts (1)
createScopedLogger(17-65)apps/web/app/api/threads/route.ts (2)
ThreadsResponse(55-55)GET(18-53)apps/web/app/api/threads/batch/route.ts (1)
GET(16-61)apps/web/app/api/messages/route.ts (1)
GET(86-102)apps/web/utils/middleware.ts (1)
withEmailProvider(258-262)
apps/web/app/api/threads/batch/route.ts (5)
apps/web/app/api/threads/route.ts (2)
ThreadsResponse(55-55)GET(18-53)apps/web/app/api/threads/basic/route.ts (1)
GET(16-40)apps/web/app/api/threads/[id]/route.ts (1)
GET(31-55)apps/web/app/api/messages/route.ts (1)
GET(86-102)apps/web/utils/middleware.ts (1)
withEmailProvider(258-262)
apps/web/app/(app)/[emailAccountId]/assistant/ExecutedRulesTable.tsx (2)
apps/web/providers/EmailAccountProvider.tsx (1)
useAccount(72-82)apps/web/utils/url.ts (1)
getEmailUrlForMessage(60-70)
apps/web/app/(app)/[emailAccountId]/bulk-unsubscribe/hooks.ts (2)
apps/web/utils/premium/index.ts (1)
hasUnsubscribeAccess(62-69)apps/web/utils/types.ts (1)
isDefined(8-10)
apps/web/app/api/messages/route.ts (2)
apps/web/utils/email/provider.ts (1)
EmailProvider(152-275)apps/web/utils/middleware.ts (1)
withEmailProvider(258-262)
apps/web/app/api/watch/all/route.ts (6)
apps/web/utils/logger.ts (1)
createScopedLogger(17-65)apps/web/utils/premium/index.ts (1)
hasAiAccess(71-85)apps/web/utils/email/provider.ts (3)
createEmailProvider(1614-1629)watchEmails(847-858)watchEmails(1589-1603)apps/web/app/api/watch/controller.ts (1)
watchEmails(8-47)apps/web/utils/cron.ts (2)
hasCronSecret(6-13)hasPostCronSecret(15-24)apps/web/utils/error.ts (1)
captureException(60-72)
apps/web/utils/email/provider.ts (3)
apps/web/providers/EmailProvider.tsx (1)
EmailProvider(56-90)apps/web/utils/gmail/watch.ts (2)
watchGmail(5-16)unwatchGmail(18-20)apps/web/utils/outlook/watch.ts (2)
watchOutlook(4-17)unwatchOutlook(19-21)
apps/web/app/api/watch/controller.ts (3)
apps/web/utils/logger.ts (1)
createScopedLogger(17-65)apps/web/utils/email/provider.ts (5)
watchEmails(847-858)watchEmails(1589-1603)EmailProvider(152-275)unwatchEmails(860-862)unwatchEmails(1605-1611)apps/web/utils/error.ts (1)
captureException(60-72)
🪛 Biome (1.9.4)
apps/web/app/api/threads/[id]/route.ts
[error] 5-5: All these imports are only used as types.
Importing the types with import type ensures that they are removed by the compilers and avoids loading unnecessary modules.
Safe fix: Use import type.
(lint/style/useImportType)
apps/web/app/api/user/stats/newsletters/route.ts
[error] 8-8: All these imports are only used as types.
Importing the types with import type ensures that they are removed by the compilers and avoids loading unnecessary modules.
Safe fix: Use import type.
(lint/style/useImportType)
apps/web/app/api/messages/route.ts
[error] 7-7: All these imports are only used as types.
Importing the types with import type ensures that they are removed by the compilers and avoids loading unnecessary modules.
Safe fix: Use import type.
(lint/style/useImportType)
apps/web/app/api/messages/batch/route.ts
[error] 5-5: All these imports are only used as types.
Importing the types with import type ensures that they are removed by the compilers and avoids loading unnecessary modules.
Safe fix: Use import type.
(lint/style/useImportType)
apps/web/app/api/threads/route.ts
[error] 3-3: Some named imports are only used as types.
This import is only used as a type.
Importing the types with import type ensures that they are removed by the compilers and avoids loading unnecessary modules.
Safe fix: Add inline type keywords.
(lint/style/useImportType)
[error] 10-10: All these imports are only used as types.
Importing the types with import type ensures that they are removed by the compilers and avoids loading unnecessary modules.
Safe fix: Use import type.
(lint/style/useImportType)
⏰ 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: Secret Detection
- GitHub Check: Jit Security
🔇 Additional comments (85)
apps/web/package.json (1)
150-154: Dev dependency change validated—no runtime imports found
A search for non–type imports of@microsoft/microsoft-graph-typesacross.ts,.tsx,.js, and.jsxfiles returned zero results. Keeping this package in devDependencies is safe.apps/web/components/SideNav.tsx (1)
71-71: LGTM! Clean refactor that consolidates destructuring.This change improves code readability by consolidating the two separate destructuring calls into a single statement while maintaining the same functionality.
apps/web/utils/encryption.ts (1)
20-21: LGTM! Environment variable rename aligns with provider abstraction.The rename from
GOOGLE_ENCRYPT_SECRET/GOOGLE_ENCRYPT_SALTtoEMAIL_ENCRYPT_SECRET/EMAIL_ENCRYPT_SALTmakes the encryption utility provider-agnostic, which aligns with the broader refactoring to support multiple email providers..github/workflows/test.yml (1)
51-52: LGTM! Environment variables updated to match the new naming convention.The test environment variables have been correctly updated to align with the provider-agnostic naming convention used throughout the codebase.
docker/Dockerfile.prod (1)
42-43: LGTM! Build-time environment variables updated consistently.The dummy build-time environment variables have been correctly updated to match the new provider-agnostic naming convention.
apps/web/utils/encryption.test.ts (1)
19-20: LGTM! Test mocks updated to match the new environment variable names.The test environment variable mocks have been correctly updated to align with the provider-agnostic naming convention, ensuring the tests continue to work properly.
apps/web/utils/outlook/spam.ts (1)
56-57: Excellent type safety improvement!The change from
anyto{ conversationId: string }provides better type safety and code clarity while maintaining the same filtering logic. This aligns with the consistent pattern of type improvements across Outlook utility files.apps/web/app/(app)/[emailAccountId]/PermissionsCheck.tsx (2)
13-13: Good architectural cleanup!Removing the unused
providervariable aligns with the broader refactoring to centralize provider handling in middleware rather than accessing it directly in UI components. This follows the learned pattern of keeping provider-specific implementation details isolated.
25-25: Dependency array correctly updated.Removing
providerfrom the dependency array is appropriate since it's no longer used in the component. The effect now only depends on the actual values it uses:routerandemailAccountId.apps/web/utils/outlook/trash.ts (1)
105-106: Consistent type safety improvement!The change from
anyto{ conversationId: string }matches the same improvement pattern in other Outlook utility files. This provides better type safety and maintains consistency across the codebase.apps/web/app/(app)/[emailAccountId]/assistant/ProcessRules.tsx (2)
55-57: Good parameter naming improvement!Changing
_indextoindexis appropriate since the parameter is actually used in the logic. The underscore prefix convention is typically used for unused parameters, so this change improves code clarity.
103-103: Consistent architectural cleanup!Removing the unused
providervariable continues the pattern of centralizing provider handling in middleware rather than accessing it directly in UI components. This aligns with the broader refactoring across the codebase.apps/web/utils/outlook/label.ts (2)
323-324: Consistent type safety improvement in archiveThread!The change from
anyto{ conversationId: string }completes the pattern of type improvements across Outlook utility files. This enhances type safety while maintaining the same filtering logic.
430-431: Consistent type safety improvement in markReadThread!The same type refinement as the other functions maintains consistency across the file and improves type safety in the manual filtering logic.
apps/web/components/GroupedTable.tsx (2)
48-48: Import cleanup aligns with provider-agnostic refactor.The removal of
getGmailUrlimport is consistent with the broader refactor to centralize provider-specific logic.
212-216: Provider parameter removal aligns with centralized provider logic.The removal of the
providerparameter fromaddToArchiveSenderQueueis consistent with the refactor to centralize provider-specific logic in utility modules.apps/web/utils/outlook/filter.ts (1)
156-156: Excellent type safety improvement.Replacing
anywith a specific object type{ displayName: string }improves type safety and code clarity. This follows the established pattern of using proper TypeScript types instead ofany.apps/web/hooks/useLabels.ts (1)
31-34: Type safety improvement enhances code quality.Replacing
color?: anywith a structured object type containingtextColorandbackgroundColorproperties significantly improves type safety and makes the color structure explicit and self-documenting.turbo.json (1)
17-18: Environment variable generalization supports multi-provider architecture.Renaming
GOOGLE_ENCRYPT_SECRET/SALTtoEMAIL_ENCRYPT_SECRET/SALTaligns with the broader refactor to support multiple email providers while maintaining consistent encryption handling.apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx (1)
31-41: Database query contradicts established Gmail-specific behavior.The addition of a database query to dynamically determine the provider conflicts with the established learning that this page should be "intentionally Gmail-specific and should show an error for non-Google email accounts rather than attempting to support multiple providers."
Consider reverting to the Gmail-specific implementation or adding explicit provider validation to maintain the intended behavior.
#!/bin/bash # Verify if this page should remain Gmail-specific based on component dependencies rg -A 10 -B 5 "gmail|google" apps/web/app/\(app\)/\[emailAccountId\]/clean/Likely an incorrect or invalid review comment.
apps/web/app/api/messages/attachment/route.ts (1)
2-6: LGTM! Middleware refactoring improves code organization.The change from
withEmailAccounttowithEmailProvidermiddleware effectively centralizes provider instantiation and eliminates redundant database queries in the handler. This aligns with the broader architectural improvement mentioned in the retrieved learnings about using abstraction layers for provider APIs.apps/web/store/archive-sender-queue.ts (1)
48-50: LGTM! Improved type safety and null checking.The explicit typing of the thread object and the use of
isDefinedfilter enhances type safety by ensuring only defined thread IDs are included in the array. This prevents potential runtime errors from undefined values.README.md (4)
27-27: LGTM! Environment variable generalization supports multi-provider architecture.The change from
GOOGLE_ENCRYPT_*toEMAIL_ENCRYPT_*in the Vercel deploy button URL properly reflects the provider-agnostic refactoring mentioned in the AI summary.
109-110: LGTM! Documentation updated to reflect generalized encryption variables.The secret variable names have been correctly updated from
GOOGLE_ENCRYPT_*toEMAIL_ENCRYPT_*to align with the provider-agnostic architecture.
323-323: LGTM! API endpoint generalization supports multiple providers.The change from
/api/google/watch/allto/api/watch/allcorrectly reflects the new provider-agnostic email watching API mentioned in the AI summary.
333-333: LGTM! Cron job configuration updated consistently.The cron job path has been correctly updated to use the new generalized API endpoint.
apps/web/components/EmailMessageCell.tsx (2)
6-6: LGTM! Improved abstraction with dedicated URL utility.The change from
getEmailUrltogetEmailUrlForMessageimproves code organization by using a dedicated utility function that encapsulates provider-specific URL generation logic.
97-97: LGTM! Cleaner function signature with explicit parameters.The updated function call with explicit
messageId,threadId,userEmail, andproviderparameters is cleaner than the previous inline conditional logic. The newgetEmailUrlForMessageutility (from apps/web/utils/url.ts lines 60-70) properly handles the provider-specific ID selection internally.apps/web/utils/auth.ts (2)
411-434: LGTM! Good refactoring for credential management.The centralized
getProviderCredentialsfunction improves code organization by consolidating OAuth client credential retrieval logic. The explicit validation for Microsoft credentials is appropriate since they're optional in the environment schema, and the error handling with logging is consistent with the codebase patterns.
437-442: Clean implementation of the credential extraction.The destructuring and usage of credentials from the helper function is clean and maintains the existing fetch request structure while improving maintainability.
apps/web/app/api/outlook/webhook/process-history.ts (4)
7-8: LGTM! Good consolidation of email provider abstractions.The import changes reflect the broader refactoring to centralize email provider handling. Moving from
@/app/api/outlook/watch/controllerto the generic@/app/api/watch/controllerand addingcreateEmailProvideraligns with the provider abstraction pattern established across the codebase.
35-35: Provider field addition supports the abstraction pattern.Adding the
providerfield to the Prisma query selection is necessary for the new provider abstraction pattern and ensures proper provider identification.
81-89: Improved abstraction with provider instances.The use of
createEmailProviderinstead of passing raw tokens tounwatchEmailsis a good improvement. The default to "microsoft-entra-id" is appropriate for this Outlook-specific webhook handler. This pattern aligns with the retrieved learnings about using abstraction layers instead of direct API calls.
97-106: Consistent provider abstraction pattern.The second instance follows the same pattern as the first, maintaining consistency in how provider instances are created and used throughout the function.
apps/web/env.ts (1)
13-14: LGTM! Environment variable generalization supports multi-provider architecture.The rename from
GOOGLE_ENCRYPT_SECRETandGOOGLE_ENCRYPT_SALTtoEMAIL_ENCRYPT_SECRETandEMAIL_ENCRYPT_SALTis appropriate for the provider abstraction refactoring. This generalization allows the same encryption keys to be used across different email providers, reducing configuration complexity.apps/web/utils/outlook/client.ts (4)
96-98: LGTM! Explicit credential validation improves error handling.The addition of explicit validation for Microsoft client credentials is appropriate since they're optional in the environment schema. This provides better error messages than runtime failures and aligns with the similar validation added in
apps/web/utils/auth.ts.
108-109: Good removal of non-null assertion operators.Using the validated credentials instead of non-null assertion operators is safer and more explicit. This ensures that the credentials are properly checked before use.
155-157: Consistent validation pattern in OAuth URL generation.The addition of credential validation in
getLinkingOAuth2Urlfollows the same pattern as the token refresh function, maintaining consistency throughout the file.
162-162: Safe usage of validated credentials.Using the validated client ID after explicit checking ensures the function operates with valid credentials.
apps/web/app/(app)/[emailAccountId]/assistant/ExecutedRulesTable.tsx (4)
8-8: LGTM! Good move to provider-agnostic URL generation.The import change from
getGmailUrltogetEmailUrlForMessagealigns with the provider abstraction refactoring and supports multiple email providers uniformly.
20-20: Appropriate addition of account context.Adding the
useAccountimport enables the component to access provider information, which is necessary for the generic URL generation function.
47-51: Updated component usage with required parameters.The addition of the
threadIdprop toOpenInGmailButtonis necessary for the new generic URL generation function that requires both message and thread IDs.
183-187: Excellent implementation of provider-agnostic URL generation.The use of
useAccountto get the provider andgetEmailUrlForMessagewith all required parameters (messageId, threadId, userEmail, provider) properly implements the provider abstraction pattern. This ensures the component works correctly with both Gmail and Outlook providers.apps/web/app/api/google/webhook/process-history.ts (5)
9-10: LGTM: Provider abstraction improvementsThe changes to use the generic watch controller and
createEmailProviderimprove the abstraction layer while maintaining backward compatibility.
41-44: LGTM: Enhanced database query for provider supportAdding
watchEmailsSubscriptionIdandproviderto the Prisma query properly supports the new provider abstraction pattern.
91-99: LGTM: Provider abstraction in unwatchEmails callsThe refactor from passing individual tokens to using a provider object is a clean improvement that centralizes provider logic.
110-119: LGTM: Consistent provider abstraction patternThe second
unwatchEmailscall follows the same improved pattern, maintaining consistency throughout the function.
139-145: Consider the mixed abstraction approachWhile the
unwatchEmailscalls now use provider abstraction, the file still contains Gmail-specific code (likegetGmailClientWithRefresh). This mixed approach might be intentional since this is specifically a Google webhook processor, but it's worth verifying this design decision aligns with the overall architecture.Should this file remain Google-specific while other parts use provider abstraction, or is there a plan to make webhook processing provider-agnostic as well?
apps/web/app/api/threads/batch/route.ts (5)
2-2: LGTM: Middleware abstraction improvementThe switch from
withEmailAccounttowithEmailProvidercentralizes provider creation and reduces boilerplate code.
4-4: LGTM: Enhanced type safetyImporting
ThreadsResponsetype improves type safety and code maintainability.
9-9: LGTM: Improved type definitionThe change from
any[]toThreadsResponse["threads"]provides better type safety and eliminates the use ofany.
16-18: LGTM: Simplified handler with middleware injectionThe refactor removes redundant database queries and provider creation logic, using the injected
emailProviderdirectly from the middleware.
49-51: LGTM: Enhanced type guardThe type guard now uses the proper
ThreadsResponse["threads"][number]type instead of a generic filter, improving type safety.apps/web/app/api/labels/create/route.ts (2)
2-2: LGTM: Middleware abstraction improvementThe switch to
withEmailProvidercentralizes provider creation and follows the consistent pattern across the refactor.
10-11: LGTM: Simplified handler with injected providerThe refactor removes redundant database queries and provider creation logic, using the injected
emailProviderdirectly from the middleware.apps/web/app/(app)/[emailAccountId]/bulk-unsubscribe/hooks.ts (4)
153-153: LGTM: Cleaned up dependency arrayRemoving the
providerparameter from the dependency array aligns with the refactor to centralize provider handling.
275-275: LGTM: Consistent dependency array cleanupThe removal of
providerfrom theuseAutoArchiveAndLabeldependency array maintains consistency with the refactor.
319-319: LGTM: Dependency array simplificationThe
useBulkAutoArchivehook's dependency array is correctly updated to remove theproviderparameter.
516-516: LGTM: Proper use of type guardThe
isDefinedfilter ensures type safety by removing null/undefined values from the thread IDs array.apps/web/app/api/labels/route.ts (2)
2-2: LGTM: Middleware abstraction improvementThe switch to
withEmailProvidercentralizes provider creation and follows the consistent refactor pattern.
23-24: LGTM: Simplified handler with injected providerThe refactor removes redundant database queries and provider creation logic, using the injected
emailProviderdirectly from the middleware. This maintains the same functionality while simplifying the code.apps/web/app/api/threads/basic/route.ts (2)
2-4: LGTM! Clean refactor to use the new middleware patternThe changes correctly implement the new
withEmailProvidermiddleware pattern, removing redundant database queries and centralizing provider instantiation. The use of the importedThreadsResponsetype also improves type consistency across the codebase.Also applies to: 16-18, 25-30
21-22: All internal consumers updated—update docs for external clientsWe searched the
apps/webcodebase and found no remaining references to the oldfolderIdparameter when calling/api/threads/basic. All internal calls now usefromEmailandlabelId(e.g., inarchive-sender-queue.tsandbulk-unsubscribe/hooks.ts).Next steps:
- Update public API documentation to reflect the new query parameters.
- Communicate this breaking change to any downstream or external API consumers.
apps/web/app/api/watch/unwatch/route.ts (1)
11-47: Well-implemented unwatch endpointThe implementation correctly uses the new
withEmailProvidermiddleware and follows best practices:
- Proper authentication via middleware
- Database query is scoped to the authenticated user
- Comprehensive error handling with appropriate logging
- Clear success/error responses with proper HTTP status codes
apps/web/utils/actions/admin.ts (1)
12-12: Excellent refactor to unified provider patternThe refactoring successfully consolidates provider-specific logic into a unified approach:
- Single Prisma query reduces database calls
- Proper provider validation with appropriate error handling
- Clean use of the
createEmailProviderfactory and unifiedprocessHistorymethod- Maintains backward compatibility while simplifying the implementation
Also applies to: 28-68
apps/web/utils/middleware.ts (1)
189-241: Well-designed email provider middlewareThe new middleware implementation is excellent:
- Properly validates email account ownership with
userIdin the WHERE clause- Comprehensive error handling for both missing accounts and provider creation failures
- Follows the established middleware pattern consistently
- Clear error messages and appropriate HTTP status codes
- Proper logging for debugging
Also applies to: 40-42, 258-262
apps/web/app/api/messages/route.ts (1)
2-2: Clean refactor to use email provider middlewareThe refactoring successfully:
- Removes database queries from the handler logic
- Uses the injected
emailProviderinstance from middleware- Maintains provider-specific filtering logic correctly
- Simplifies the code while preserving functionality
Also applies to: 18-25, 54-54, 65-65, 86-89, 99-99
apps/web/app/api/user/stats/newsletters/route.ts (3)
70-77: Good refactor to accept injected provider.The function signature change aligns with the new middleware pattern, eliminating redundant database queries and provider instantiation.
223-227: Improved error handling with type checks.Good defensive programming to check error instance before accessing properties.
245-268: Correct implementation of new middleware pattern.The GET handler properly uses the injected
emailProviderfrom the middleware, maintaining consistency across the codebase.apps/web/app/api/messages/batch/route.ts (2)
11-31: Clean refactor following the new provider pattern.The function correctly delegates to the injected provider instance.
33-51: Consistent implementation with new middleware.apps/web/app/api/watch/controller.ts (1)
8-47: Well-structured watch email implementation.The function properly handles provider-specific differences (subscription ID for Microsoft only) and includes comprehensive error handling.
apps/web/app/api/threads/[id]/route.ts (2)
13-25: Clean refactor with simplified function signature.
31-55: Proper error handling with contextual logging.Good implementation with appropriate error handling and contextual information in logs.
apps/web/app/api/watch/route.ts (1)
16-92: Approved: Prisma query correctly scoped to the authenticated user.The
findManycall in apps/web/app/api/watch/route.ts includeswhere: { userId }, properly enforcing ownership per our security guidelines. No changes needed here.apps/web/providers/EmailProvider.tsx (1)
57-82: Good improvement to loading state managementThe changes correctly handle loading states from both the account and labels, preventing the component from processing incomplete data.
apps/web/app/api/user/stats/newsletters/helpers.ts (1)
100-103: Verify Outlook auto-archive filter detection logicThe comment mentions "moves to archive folder" but the implementation only checks for INBOX removal. This might miss cases where emails are moved to a specific archive folder.
Please verify if Outlook filters use a specific
addLabelIdsfor archive folders or if INBOX removal is sufficient for detecting auto-archive behavior.apps/web/utils/user/delete.ts (1)
36-54: Well-implemented provider abstractionThe changes properly handle the transition from raw tokens to EmailProvider instances, with appropriate null checks and conditional provider creation.
apps/web/app/api/watch/all/route.ts (1)
131-147: Proper cron endpoint security implementationThe endpoint correctly implements cron secret validation for both GET and POST methods, following security best practices.
apps/web/app/api/threads/route.ts (1)
18-53: Clean implementation of provider middleware patternThe refactor to use
withEmailProvidermiddleware properly centralizes provider creation and improves consistency across API routes.apps/web/utils/url.ts (1)
55-70: LGTM! Well-documented provider-aware URL generation.The function documentation clearly explains the behavior for different providers, and the implementation correctly delegates to provider-specific configuration.
apps/web/utils/email/provider.ts (3)
1130-1150: Good type safety improvement for Outlook filters.The explicit typing for the filter mapping improves code clarity and prevents potential runtime errors.
1424-1447: Excellent defensive programming with conversationId validation.The code properly handles missing
conversationIdwith logging, preventing potential runtime errors while maintaining visibility of the issue.
1574-1578: Good validation for required subscriptionId parameter.The early validation with a clear error message helps catch integration issues quickly.
| categories: CategoryWithRules[]; | ||
| }) { | ||
| const { emailAccountId, userEmail, provider } = useAccount(); | ||
| const { emailAccountId, userEmail } = useAccount(); |
Contributor
There was a problem hiding this comment.
Provider removal from useAccount() is inconsistent with usage below.
While provider was removed from the destructuring here, it's still being used in the ExpandedRows component at line 524. This creates an inconsistency.
🤖 Prompt for AI Agents
In apps/web/components/GroupedTable.tsx at line 78, the destructuring of
useAccount() removes the provider, but provider is still used later in the
ExpandedRows component around line 524. To fix this inconsistency, include
provider in the destructuring assignment from useAccount() at line 78 so it is
available where needed.
Comment on lines
+76
to
+83
| await prisma.emailAccount.update({ | ||
| where: { email: emailAccount.email }, | ||
| data: { | ||
| watchEmailsExpirationDate: null, | ||
| watchEmailsSubscriptionId: null, | ||
| }, | ||
| }); | ||
| } |
Contributor
There was a problem hiding this comment.
Use emailAccount.id instead of email for database update
Using email as the unique identifier could cause issues if emails are not guaranteed to be unique across accounts.
await prisma.emailAccount.update({
- where: { email: emailAccount.email },
+ where: { id: emailAccount.id },
data: {
watchEmailsExpirationDate: null,
watchEmailsSubscriptionId: null,
},
});📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| await prisma.emailAccount.update({ | |
| where: { email: emailAccount.email }, | |
| data: { | |
| watchEmailsExpirationDate: null, | |
| watchEmailsSubscriptionId: null, | |
| }, | |
| }); | |
| } | |
| await prisma.emailAccount.update({ | |
| where: { id: emailAccount.id }, | |
| data: { | |
| watchEmailsExpirationDate: null, | |
| watchEmailsSubscriptionId: null, | |
| }, | |
| }); |
🤖 Prompt for AI Agents
In apps/web/app/api/watch/all/route.ts between lines 76 and 83, the
prisma.emailAccount.update call uses emailAccount.email as the unique identifier
in the where clause, which may not be unique. Change the where clause to use
emailAccount.id instead to ensure the update targets the correct record
reliably.
Comment on lines
+1339
to
+1342
| // Add folder filter based on type or labelId | ||
| if (query?.labelId) { | ||
| // Use labelId as parentFolderId (should be lowercase for Outlook) | ||
| filters.push(`parentFolderId eq '${query.labelId.toLowerCase()}'`); |
Contributor
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Verify labelId case conversion for Outlook compatibility.
The code converts labelId to lowercase for Outlook. Please ensure this is consistently handled across the codebase and that the label IDs from Outlook are always lowercase.
🏁 Script executed:
#!/bin/bash
# Description: Check how labelId is handled in other parts of the codebase for Outlook
# Search for labelId usage in Outlook-related code
rg -A 3 -B 3 "labelId.*[Oo]utlook|[Oo]utlook.*labelId" --type ts
# Check if there are any uppercase label IDs being used with Outlook
ast-grep --pattern 'labelId: $_' apps/web/utils/outlook/Length of output: 2174
Let’s inspect the getOutlookLabels implementation to see if it normalizes folder IDs to lowercase:
🏁 Script executed:
#!/bin/bash
# Locate files defining or referencing getOutlookLabels
echo "Files containing getOutlookLabels:"
rg -l "getOutlookLabels" -R apps/web/utils/outlook
# Show the implementation context for getOutlookLabels
echo -e "\nContext around getOutlookLabels definition:"
rg -A5 -B5 "getOutlookLabels" apps/web/utils/outlook/*.tsLength of output: 3976
Let’s inspect the full implementation of getOutlookLabels to verify whether it lowercases folder IDs:
🏁 Script executed:
#!/bin/bash
# Show the implementation of getOutlookLabels in apps/web/utils/outlook/message.ts
rg -n "function getOutlookLabels" -A30 -B5 apps/web/utils/outlook/message.tsLength of output: 1213
Remove unnecessary lowercase conversion on Outlook folder IDs
The Outlook Graph API expects the exact folder ID as returned—not a lowercased version. Converting labelId to lowercase will prevent the filter from matching the real parentFolderId. Replace:
// Before
filters.push(`parentFolderId eq '${query.labelId.toLowerCase()}'`);with:
// After
filters.push(`parentFolderId eq '${query.labelId}'`);• File: apps/web/utils/email/provider.ts
Lines 1339–1342
This aligns with how getOutlookLabels matches IDs (exact string comparison) and ensures the filter works consistently.
🤖 Prompt for AI Agents
In apps/web/utils/email/provider.ts around lines 1339 to 1342, remove the call
to toLowerCase() on query.labelId when adding the parentFolderId filter for
Outlook. Instead of converting labelId to lowercase, use the exact labelId
string as returned by the API to ensure the filter matches the real
parentFolderId correctly.
Contributor
There was a problem hiding this comment.
Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!
Contributor
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
apps/web/app/api/watch/route.ts (1)
2-2: Remove unused import.The
withEmailProviderimport is not used in this file. Based on the past review comment, the route correctly useswithAuthinstead since it handles multiple email accounts internally.-import { withAuth, withEmailProvider } from "@/utils/middleware"; +import { withAuth } from "@/utils/middleware";
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
apps/web/app/api/watch/route.ts(1 hunks)
🧰 Additional context used
📓 Path-based instructions (3)
`apps/web/**/*.{ts,tsx}`: Use TypeScript with strict null checks Path aliases: U...
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
📄 Source: CodeRabbit Inference Engine (apps/web/CLAUDE.md)
List of files the instruction was applied to:
apps/web/app/api/watch/route.ts
`apps/web/app/**/*`: NextJS app router structure with (app) directory
apps/web/app/**/*: NextJS app router structure with (app) directory
📄 Source: CodeRabbit Inference Engine (apps/web/CLAUDE.md)
List of files the instruction was applied to:
apps/web/app/api/watch/route.ts
`**/*.{ts,tsx}`: Define validation schemas using Zod Apply the same validation in both client and server Use descriptive error messages
**/*.{ts,tsx}: Define validation schemas using Zod
Apply the same validation in both client and server
Use descriptive error messages
📄 Source: CodeRabbit Inference Engine (.cursor/rules/form-handling.mdc)
List of files the instruction was applied to:
apps/web/app/api/watch/route.ts
🧠 Learnings (2)
📓 Common learnings
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Keep provider-specific implementation details isolated within their respective utility directories (e.g., apps/web/utils/gmail/ for Gmail), which allows for easier addition of new providers in the future.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Never call provider APIs (such as Gmail) directly from routes or components; always use abstraction layers provided by utility wrapper functions.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Always use wrapper functions from the utils folder (e.g., apps/web/utils/gmail/message.ts) to interact with provider APIs, ensuring maintainability and easier future provider support.
Learnt from: elie222
PR: elie222/inbox-zero#537
File: apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx:30-34
Timestamp: 2025-07-08T13:14:07.449Z
Learning: The clean onboarding page in apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx is intentionally Gmail-specific and should show an error for non-Google email accounts rather than attempting to support multiple providers.
apps/web/app/api/watch/route.ts (13)
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: In Next.js App Router, GET API route handlers should be wrapped with either `withAuth` or `withEmailAccount` middleware to ensure consistent error handling and authentication.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: In Next.js API routes under apps/web/app/api/, always use authentication middleware such as withAuth or withEmailAccount, or ensure custom authentication logic is present if using withError.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-06-23T12:27:17.978Z
Learning: In Next.js/TypeScript API routes, always use authentication middleware (withAuth for user-level, withEmailAccount for account-level) to protect endpoints that handle user data.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: When using `withAuth` or `withEmailAccount` middleware in GET API routes, explicit try/catch blocks are unnecessary because the middleware handles errors.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: Response types for GET API routes in Next.js can be inferred and exported using `Awaited<ReturnType<typeof getData>>`, eliminating the need for manual type definitions.
Learnt from: elie222
PR: elie222/inbox-zero#537
File: apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx:30-34
Timestamp: 2025-07-08T13:14:07.449Z
Learning: The clean onboarding page in apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx is intentionally Gmail-specific and should show an error for non-Google email accounts rather than attempting to support multiple providers.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Never call provider APIs (such as Gmail) directly from routes or components; always use abstraction layers provided by utility wrapper functions.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-06-23T12:26:14.189Z
Learning: Always use wrapper functions from the utils folder (e.g., apps/web/utils/gmail/message.ts) to interact with provider APIs, ensuring maintainability and easier future provider support.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/security-audit.mdc:0-0
Timestamp: 2025-06-23T12:27:05.686Z
Learning: All Prisma queries in API routes must be scoped to the current user or account by including emailAccountId or userId in the WHERE clause to prevent unauthorized data access (IDOR vulnerabilities).
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/data-fetching.mdc:0-0
Timestamp: 2025-07-03T12:02:38.024Z
Learning: Applies to **/*.tsx : For API GET requests to server, use the `swr` package
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-06-23T12:26:11.276Z
Learning: Responses from GET API routes in Next.js should be returned using `NextResponse.json()` for consistency and proper response formatting.
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/data-fetching.mdc:0-0
Timestamp: 2025-07-03T12:02:38.024Z
Learning: For mutating data, use Next.js server actions
Learnt from: CR
PR: elie222/inbox-zero#0
File: .cursor/rules/ui-components.mdc:0-0
Timestamp: 2025-06-23T12:27:33.499Z
Learning: When fetching data from an API in a Next.js React application, use the `swr` package for GET requests to the server. This provides built-in caching, revalidation, and error handling.
⏰ 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). (1)
- GitHub Check: Jit Security
🔇 Additional comments (5)
apps/web/app/api/watch/route.ts (5)
12-12: Good use of appropriate middleware.The route correctly uses
withAuthmiddleware instead ofwithEmailProvidersince it handles multiple email accounts internally rather than operating on a single account injected by middleware.
16-29: Proper user scoping for data access.The Prisma query correctly scopes data access to the authenticated user with
where: { userId }, preventing unauthorized data access. The selected fields are appropriate for the operation.
40-49: Good validation for authentication tokens.The code properly validates that required tokens exist before proceeding with watch setup, providing clear error messages when tokens are missing.
52-55: Correct use of email provider abstraction.The code properly uses
createEmailProviderabstraction instead of calling provider APIs directly, which aligns with the established architectural pattern for provider-agnostic email handling.
76-88: Comprehensive error handling with detailed logging.The exception handling provides both user-friendly error messages and detailed logging for debugging, while safely handling different error types.
elie222
reviewed
Jul 11, 2025
|
|
||
| let category = categories.value.find( | ||
| (cat: any) => cat.displayName === categoryName, | ||
| (cat: { displayName: string }) => cat.displayName === categoryName, |
Owner
There was a problem hiding this comment.
Categories isn't typed automatically so we don't need to type it here?
Or TS thinks it's any type?
Merged
This was referenced Aug 29, 2025
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary by CodeRabbit
New Features
Refactor
Bug Fixes
Chores
Style