Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
WalkthroughThis PR updates many package dependencies across the monorepo, removes several unused imports, refactors Gmail filter error handling to use a GaxiosError type guard, adds two biome lint rules, and adjusts better-auth patches to nullify session.user.image during cookie caching. Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant GmailUtil as Gmail Filter Utility
participant GoogleAPI as Google API
participant GaxiosGuard as GaxiosError Guard
Client->>GmailUtil: request createFilter(...)
GmailUtil->>GoogleAPI: call filters.create(...)
alt success
GoogleAPI-->>GmailUtil: 200 created
GmailUtil-->>Client: return created filter
else error
GoogleAPI-->>GmailUtil: error
GmailUtil->>GaxiosGuard: isFilterExistsError(error)
rect rgb(220, 245, 220)
Note over GaxiosGuard: New behavior — verifies error is a GaxiosError\nand message contains "Filter already exists"
end
alt guard true
GaxiosGuard-->>GmailUtil: true
GmailUtil-->>Client: handle "already exists" as success path
else guard false
GaxiosGuard-->>GmailUtil: false
GmailUtil-->>Client: propagate error
end
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (1 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (2)
🧰 Additional context used📓 Path-based instructions (14)apps/web/**/*.{ts,tsx}📄 CodeRabbit inference engine (apps/web/CLAUDE.md)
Files:
apps/web/app/**📄 CodeRabbit inference engine (apps/web/CLAUDE.md)
Files:
apps/web/**/*.tsx📄 CodeRabbit inference engine (apps/web/CLAUDE.md)
Files:
!{.cursor/rules/*.mdc}📄 CodeRabbit inference engine (.cursor/rules/cursor-rules.mdc)
Files:
**/*.tsx📄 CodeRabbit inference engine (.cursor/rules/form-handling.mdc)
Files:
**/*.{ts,tsx}📄 CodeRabbit inference engine (.cursor/rules/logging.mdc)
Files:
apps/web/app/(app)/*/**📄 CodeRabbit inference engine (.cursor/rules/page-structure.mdc)
Files:
apps/web/app/(app)/*/**/*.tsx📄 CodeRabbit inference engine (.cursor/rules/page-structure.mdc)
Files:
apps/web/app/(app)/*/**/**/*.tsx📄 CodeRabbit inference engine (.cursor/rules/page-structure.mdc)
Files:
apps/web/app/**/*.tsx📄 CodeRabbit inference engine (.cursor/rules/project-structure.mdc)
Files:
**/*.{js,jsx,ts,tsx}📄 CodeRabbit inference engine (.cursor/rules/ultracite.mdc)
Files:
!pages/_document.{js,jsx,ts,tsx}📄 CodeRabbit inference engine (.cursor/rules/ultracite.mdc)
Files:
**/*.{jsx,tsx}📄 CodeRabbit inference engine (.cursor/rules/ultracite.mdc)
Files:
**/*.{html,jsx,tsx}📄 CodeRabbit inference engine (.cursor/rules/ultracite.mdc)
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
📜 Review details
Configuration used: Path: .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 (18)
apps/unsubscriber/package.json(1 hunks)apps/web/app/(app)/[emailAccountId]/calendars/CalendarConnectionCard.tsx(1 hunks)apps/web/app/api/sso/signin/route.test.ts(1 hunks)apps/web/components/NavUser.tsx(0 hunks)apps/web/components/SideNavWithTopNav.tsx(0 hunks)apps/web/package.json(6 hunks)apps/web/utils/action-display.tsx(0 hunks)apps/web/utils/gmail/filter.ts(2 hunks)apps/web/utils/gmail/mail.ts(0 hunks)biome.json(1 hunks)package.json(2 hunks)packages/loops/package.json(1 hunks)packages/resend/package.json(1 hunks)packages/tinybird-ai-analytics/package.json(1 hunks)packages/tinybird/package.json(1 hunks)patches/better-auth@1.3.28.patch(1 hunks)patches/better-auth@1.3.7.patch(0 hunks)version.txt(1 hunks)
💤 Files with no reviewable changes (5)
- apps/web/utils/gmail/mail.ts
- apps/web/utils/action-display.tsx
- apps/web/components/SideNavWithTopNav.tsx
- patches/better-auth@1.3.7.patch
- apps/web/components/NavUser.tsx
🧰 Additional context used
📓 Path-based instructions (22)
apps/web/**/*.{ts,tsx}
📄 CodeRabbit inference engine (apps/web/CLAUDE.md)
apps/web/**/*.{ts,tsx}: Use TypeScript with strict null checks
Path aliases: Use@/for imports from project root
Use proper error handling with try/catch blocks
Format code with Prettier
Leverage TypeScript inference for better DX
Files:
apps/web/app/(app)/[emailAccountId]/calendars/CalendarConnectionCard.tsxapps/web/app/api/sso/signin/route.test.tsapps/web/utils/gmail/filter.ts
apps/web/app/**
📄 CodeRabbit inference engine (apps/web/CLAUDE.md)
NextJS app router structure with (app) directory
Files:
apps/web/app/(app)/[emailAccountId]/calendars/CalendarConnectionCard.tsxapps/web/app/api/sso/signin/route.test.ts
apps/web/**/*.tsx
📄 CodeRabbit inference engine (apps/web/CLAUDE.md)
apps/web/**/*.tsx: Follow tailwindcss patterns with prettier-plugin-tailwindcss
Prefer functional components with hooks
Use shadcn/ui components when available
Ensure responsive design with mobile-first approach
Follow consistent naming conventions (PascalCase for components)
Use LoadingContent component for async data
Useresult?.serverErrorwithtoastErrorandtoastSuccess
UseLoadingContentcomponent to handle loading and error states consistently
Passloading,error, and children props toLoadingContent
Files:
apps/web/app/(app)/[emailAccountId]/calendars/CalendarConnectionCard.tsx
!{.cursor/rules/*.mdc}
📄 CodeRabbit inference engine (.cursor/rules/cursor-rules.mdc)
Never place rule files in the project root, in subdirectories outside .cursor/rules, or in any other location
Files:
apps/web/app/(app)/[emailAccountId]/calendars/CalendarConnectionCard.tsxpackages/loops/package.jsonapps/unsubscriber/package.jsonpackage.jsonversion.txtbiome.jsonpatches/better-auth@1.3.28.patchapps/web/app/api/sso/signin/route.test.tspackages/tinybird-ai-analytics/package.jsonpackages/resend/package.jsonpackages/tinybird/package.jsonapps/web/utils/gmail/filter.tsapps/web/package.json
**/*.tsx
📄 CodeRabbit inference engine (.cursor/rules/form-handling.mdc)
**/*.tsx: Use React Hook Form with Zod for validation
Validate form inputs before submission
Show validation errors inline next to form fields
Files:
apps/web/app/(app)/[emailAccountId]/calendars/CalendarConnectionCard.tsx
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/logging.mdc)
**/*.{ts,tsx}: UsecreateScopedLoggerfor logging in backend TypeScript files
Typically add the logger initialization at the top of the file when usingcreateScopedLogger
Only use.with()on a logger instance within a specific function, not for a global loggerImport Prisma in the project using
import prisma from "@/utils/prisma";
**/*.{ts,tsx}: Don't use TypeScript enums.
Don't use TypeScript const enum.
Don't use the TypeScript directive @ts-ignore.
Don't use primitive type aliases or misleading types.
Don't use empty type parameters in type aliases and interfaces.
Don't use any or unknown as type constraints.
Don't use implicit any type on variable declarations.
Don't let variables evolve into any type through reassignments.
Don't use non-null assertions with the ! postfix operator.
Don't misuse the non-null assertion operator (!) in TypeScript files.
Don't use user-defined types.
Use as const instead of literal types and type annotations.
Use export type for types.
Use import type for types.
Don't declare empty interfaces.
Don't merge interfaces and classes unsafely.
Don't use overload signatures that aren't next to each other.
Use the namespace keyword instead of the module keyword to declare TypeScript namespaces.
Don't use TypeScript namespaces.
Don't export imported variables.
Don't add type annotations to variables, parameters, and class properties that are initialized with literal expressions.
Don't use parameter properties in class constructors.
Use either T[] or Array consistently.
Initialize each enum member value explicitly.
Make sure all enum members are literal values.
Files:
apps/web/app/(app)/[emailAccountId]/calendars/CalendarConnectionCard.tsxapps/web/app/api/sso/signin/route.test.tsapps/web/utils/gmail/filter.ts
apps/web/app/(app)/*/**
📄 CodeRabbit inference engine (.cursor/rules/page-structure.mdc)
Components for the page are either put in page.tsx, or in the apps/web/app/(app)/PAGE_NAME folder
Files:
apps/web/app/(app)/[emailAccountId]/calendars/CalendarConnectionCard.tsx
apps/web/app/(app)/*/**/*.tsx
📄 CodeRabbit inference engine (.cursor/rules/page-structure.mdc)
If you need to use onClick in a component, that component is a client component and file must start with 'use client'
Files:
apps/web/app/(app)/[emailAccountId]/calendars/CalendarConnectionCard.tsx
apps/web/app/(app)/*/**/**/*.tsx
📄 CodeRabbit inference engine (.cursor/rules/page-structure.mdc)
If we're in a deeply nested component we will use swr to fetch via API
Files:
apps/web/app/(app)/[emailAccountId]/calendars/CalendarConnectionCard.tsx
apps/web/app/**/*.tsx
📄 CodeRabbit inference engine (.cursor/rules/project-structure.mdc)
Components with
onClickmust be client components withuse clientdirective
Files:
apps/web/app/(app)/[emailAccountId]/calendars/CalendarConnectionCard.tsx
**/*.{js,jsx,ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/ultracite.mdc)
**/*.{js,jsx,ts,tsx}: Don't useelements in Next.js projects.
Don't use elements in Next.js projects.
Don't use namespace imports.
Don't access namespace imports dynamically.
Don't use global eval().
Don't use console.
Don't use debugger.
Don't use var.
Don't use with statements in non-strict contexts.
Don't use the arguments object.
Don't use consecutive spaces in regular expression literals.
Don't use the comma operator.
Don't use unnecessary boolean casts.
Don't use unnecessary callbacks with flatMap.
Use for...of statements instead of Array.forEach.
Don't create classes that only have static members (like a static namespace).
Don't use this and super in static contexts.
Don't use unnecessary catch clauses.
Don't use unnecessary constructors.
Don't use unnecessary continue statements.
Don't export empty modules that don't change anything.
Don't use unnecessary escape sequences in regular expression literals.
Don't use unnecessary labels.
Don't use unnecessary nested block statements.
Don't rename imports, exports, and destructured assignments to the same name.
Don't use unnecessary string or template literal concatenation.
Don't use String.raw in template literals when there are no escape sequences.
Don't use useless case statements in switch statements.
Don't use ternary operators when simpler alternatives exist.
Don't use useless this aliasing.
Don't initialize variables to undefined.
Don't use the void operators (they're not familiar).
Use arrow functions instead of function expressions.
Use Date.now() to get milliseconds since the Unix Epoch.
Use .flatMap() instead of map().flat() when possible.
Use literal property access instead of computed property access.
Don't use parseInt() or Number.parseInt() when binary, octal, or hexadecimal literals work.
Use concise optional chaining instead of chained logical expressions.
Use regular expression literals instead of the RegExp constructor when possible.
Don't use number literal object member names th...
Files:
apps/web/app/(app)/[emailAccountId]/calendars/CalendarConnectionCard.tsxapps/web/app/api/sso/signin/route.test.tsapps/web/utils/gmail/filter.ts
!pages/_document.{js,jsx,ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/ultracite.mdc)
!pages/_document.{js,jsx,ts,tsx}: Don't import next/document outside of pages/_document.jsx in Next.js projects.
Don't import next/document outside of pages/_document.jsx in Next.js projects.
Files:
apps/web/app/(app)/[emailAccountId]/calendars/CalendarConnectionCard.tsxpackages/loops/package.jsonapps/unsubscriber/package.jsonpackage.jsonversion.txtbiome.jsonpatches/better-auth@1.3.28.patchapps/web/app/api/sso/signin/route.test.tspackages/tinybird-ai-analytics/package.jsonpackages/resend/package.jsonpackages/tinybird/package.jsonapps/web/utils/gmail/filter.tsapps/web/package.json
**/*.{jsx,tsx}
📄 CodeRabbit inference engine (.cursor/rules/ultracite.mdc)
**/*.{jsx,tsx}: Don't destructure props inside JSX components in Solid projects.
Don't use both children and dangerouslySetInnerHTML props on the same element.
Don't use Array index in keys.
Don't assign to React component props.
Don't define React components inside other components.
Don't use event handlers on non-interactive elements.
Don't assign JSX properties multiple times.
Don't add extra closing tags for components without children.
Use <>...</> instead of ....
Don't insert comments as text nodes.
Don't use the return value of React.render.
Make sure all dependencies are correctly specified in React hooks.
Make sure all React hooks are called from the top level of component functions.
Don't use unnecessary fragments.
Don't pass children as props.
Use semantic elements instead of role attributes in JSX.
Files:
apps/web/app/(app)/[emailAccountId]/calendars/CalendarConnectionCard.tsx
**/*.{html,jsx,tsx}
📄 CodeRabbit inference engine (.cursor/rules/ultracite.mdc)
**/*.{html,jsx,tsx}: Don't use or elements.
Don't use accessKey attribute on any HTML element.
Don't set aria-hidden="true" on focusable elements.
Don't add ARIA roles, states, and properties to elements that don't support them.
Only use the scope prop on elements.
Don't assign non-interactive ARIA roles to interactive HTML elements.
Make sure label elements have text content and are associated with an input.
Don't assign interactive ARIA roles to non-interactive HTML elements.
Don't assign tabIndex to non-interactive HTML elements.
Don't use positive integers for tabIndex property.
Don't include "image", "picture", or "photo" in img alt prop.
Don't use explicit role property that's the same as the implicit/default role.
Make static elements with click handlers use a valid role attribute.
Always include a title element for SVG elements.
Give all elements requiring alt text meaningful information for screen readers.
Make sure anchors have content that's accessible to screen readers.
Assign tabIndex to non-interactive HTML elements with aria-activedescendant.
Include all required ARIA attributes for elements with ARIA roles.
Make sure ARIA properties are valid for the element's supported roles.
Always include a type attribute for button elements.
Make elements with interactive roles and handlers focusable.
Give heading elements content that's accessible to screen readers (not hidden with aria-hidden).
Always include a lang attribute on the html element.
Always include a title attribute for iframe elements.
Accompany onClick with at least one of: onKeyUp, onKeyDown, or onKeyPress.
Accompany onMouseOver/onMouseOut with onFocus/onBlur.
Include caption tracks for audio and video elements.
Make sure all anchors are valid and navigable.
Ensure all ARIA properties (aria-*) are valid.
Use valid, non-abstract ARIA roles for elements with ARIA roles.
Use valid ARIA state and property values.
Use valid values for the autocomplete attribute on input eleme...Files:
apps/web/app/(app)/[emailAccountId]/calendars/CalendarConnectionCard.tsx**/*.ts
📄 CodeRabbit inference engine (.cursor/rules/form-handling.mdc)
**/*.ts: The same validation should be done in the server action too
Define validation schemas using ZodFiles:
apps/web/app/api/sso/signin/route.test.tsapps/web/utils/gmail/filter.ts**/*.test.{ts,js}
📄 CodeRabbit inference engine (.cursor/rules/security.mdc)
Include security tests in your test suites to verify authentication, authorization, and error handling.
Files:
apps/web/app/api/sso/signin/route.test.tsapps/web/app/api/**/*.{ts,js}
📄 CodeRabbit inference engine (.cursor/rules/security-audit.mdc)
apps/web/app/api/**/*.{ts,js}: All API route handlers in 'apps/web/app/api/' must use authentication middleware: withAuth, withEmailAccount, or withError (with custom authentication logic).
All Prisma queries in API routes must include user/account filtering (e.g., emailAccountId or userId in WHERE clauses) to prevent unauthorized data access.
All parameters used in API routes must be validated before use; do not use parameters from 'params' or request bodies directly in queries without validation.
Request bodies in API routes should use Zod schemas for validation.
API routes should only return necessary fields using Prisma's 'select' and must not include sensitive data in error messages.
Error messages in API routes must not reveal internal details; use generic errors and SafeError for user-facing errors.
All QStash endpoints (API routes called via publishToQstash or publishToQstashQueue) must use verifySignatureAppRouter to verify request authenticity.
All cron endpoints in API routes must use hasCronSecret or hasPostCronSecret for authentication.
Do not hardcode weak or plaintext secrets in API route files; secrets must not be directly assigned as string literals.
Review all new withError usage in API routes to ensure custom authentication is implemented where required.Files:
apps/web/app/api/sso/signin/route.test.ts**/*.{test,spec}.{js,jsx,ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/ultracite.mdc)
**/*.{test,spec}.{js,jsx,ts,tsx}: Don't use export or module.exports in test files.
Don't use focused tests.
Don't use disabled tests.
Make sure the assertion function, like expect, is placed inside an it() function call.
Don't nest describe() blocks too deeply in test files.
Don't use focused tests.
Don't use disabled tests.
Don't use export or module.exports in test files.Files:
apps/web/app/api/sso/signin/route.test.ts**/*.test.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/testing.mdc)
**/*.test.{ts,tsx}: Use Vitest (vitest) as the testing framework
Colocate tests next to the file under test (e.g., dir/format.ts with dir/format.test.ts)
In tests, mock theserver-onlymodule withvi.mock("server-only", () => ({}));
When testing code that uses Prisma, mock it withvi.mock("@/utils/prisma")and use the mock from@/utils/__mocks__/prisma
Use provided helpers for mocks: import{ getEmail, getEmailAccount, getRule }from@/__tests__/helpers
Each test should be independent
Use descriptive test names
Mock external dependencies in tests
Clean up mocks between tests (e.g.,vi.clearAllMocks()inbeforeEach)
Avoid testing implementation details; focus on observable behavior
Do not mock the LoggerFiles:
apps/web/app/api/sso/signin/route.test.tsapps/web/utils/gmail/**/*.ts
📄 CodeRabbit inference engine (.cursor/rules/gmail-api.mdc)
Keep provider-specific implementation details isolated in the appropriate utils subfolder (e.g., 'apps/web/utils/gmail/')
Files:
apps/web/utils/gmail/filter.tsapps/web/utils/**
📄 CodeRabbit inference engine (.cursor/rules/project-structure.mdc)
Create utility functions in
utils/folder for reusable logicFiles:
apps/web/utils/gmail/filter.tsapps/web/utils/**/*.ts
📄 CodeRabbit inference engine (.cursor/rules/project-structure.mdc)
apps/web/utils/**/*.ts: Use lodash utilities for common operations (arrays, objects, strings)
Import specific lodash functions to minimize bundle sizeFiles:
apps/web/utils/gmail/filter.ts🧠 Learnings (1)
📚 Learning: 2025-10-02T23:23:48.064Z
Learnt from: CR PR: elie222/inbox-zero#0 File: .cursor/rules/llm-test.mdc:0-0 Timestamp: 2025-10-02T23:23:48.064Z Learning: Applies to apps/web/__tests__/**/*.test.ts : Use Vitest in LLM tests and import { describe, expect, test, vi, beforeEach } from "vitest"Applied to files:
apps/web/app/api/sso/signin/route.test.ts⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Jit Security
🔇 Additional comments (14)
apps/web/app/(app)/[emailAccountId]/calendars/CalendarConnectionCard.tsx (1)
11-11: Inconsistency between summary and code.The AI-generated summary claims "Removed the Trash2 icon from the lucide-react import, leaving only XCircle," but the current code still imports both
Trash2andXCircle. Both imports are actively used (Trash2 on line 131, XCircle on line 118), so the import is correct as-is.version.txt (1)
1-1: LGTM!Version bump to v2.17.2 is consistent with the package updates in this PR.
apps/web/app/api/sso/signin/route.test.ts (1)
30-30: LGTM!Good cleanup of unused imports. The test file only uses
NextRequest, so removingSafeErrorandNextResponseimproves maintainability.packages/loops/package.json (1)
6-11: LGTM!Patch-level dependency updates for loops, @types/node, and TypeScript. These minor bumps should be safe and include bug fixes.
biome.json (1)
37-44: LGTM!Added explicit rule configurations for
noAlertanduseArrowFunction, both set to "off". This provides clarity on which rules are intentionally disabled without changing linting behavior.patches/better-auth@1.3.28.patch (1)
9-9: No breaking changes. The patch is safe.Verification confirms the application doesn't access
session.user.imageanywhere. All image references in the codebase come from database objects (user.imagein dub.ts,account.imagein email-accounts route,emailAccount?.imagein components), not from the session cookie. The patch safely reduces cookie size by nullifying the image field before storage, following security and performance best practices.packages/tinybird-ai-analytics/package.json (1)
7-7: Verify @chronark/zod-bird compatibility with Zod v4 before upgrading.No code changes were made between the latest 3.25.x release and 4.0.0, and libraries implementing Zod 4 support by updating peer dependencies to "zod": "^3.25.0 || ^4.0.0" should require no other code changes. The schema in
packages/tinybird-ai-analytics/src/publish.tsuses only foundational APIs (z.object, z.string, z.number, .int(), .optional(), z.infer) that remain stable across versions.However, verify that
@chronark/zod-birdhas been tested or updated to support Zod v4 by checking:
- Its GitHub releases or npm package page for v4 compatibility notes
- Its
peerDependenciesfield to confirm it accepts"zod": "^4.0.0"Once confirmed, proceed with testing to ensure validation behavior remains unchanged.
packages/resend/package.json (1)
12-13: No compatibility issues detected — React 19.2.0 is compatible with react-email 4.3.1.The react-email package and its ecosystem have been officially updated to support React 19. The resend package shows minimal React usage (type-only imports in send.tsx) and correctly aligns react-email 4.3.1 with react 19.2.0. The dependency versions are stable and compatible.
package.json (2)
16-24: LGTM! Minor version updates look safe.The updates to turbo, lint-staged, and pnpm are minor version bumps that should be backward compatible. The pnpm update from 10.17.1 to 10.19.0 may include performance improvements and bug fixes.
39-39: Patch is compatible; no breaking changes detected.The patch adds
session.user.image = null;to thesetCookieCachefunction in better-auth 1.3.28's compiled output. This appears intentional—likely a security measure or bug fix. The codebase doesn't depend onsession.user.imagefor functionality; user images are fetched from OAuth providers (Google/Microsoft) inapps/web/utils/auth.tsand stored in database models, not retrieved from session cookies. The session object is used only for user identification across the app (PostHogProvider, MultiAccountSection, etc.).The version jump from 1.3.7 to 1.3.28 is significant, but the patch itself is safe and addresses session handling without introducing breaking changes.
apps/web/utils/gmail/filter.ts (1)
65-70: Now let me verify if there are tests for this error handling or other error patterns in the codebase:Error handling implementation is correct; GaxiosError.message is the appropriate property to check.
Based on verification of GaxiosError documentation and Google's auth library implementation patterns, the GaxiosError constructor receives a message string parameter that is inherited from the Error class. Google's own auth library sets err.message based on response body error content, confirming that checking
error.message.includes("Filter already exists")is the correct approach. The type guard is properly implemented using a standard Error property that has remained consistent across all gaxios versions.apps/unsubscriber/package.json (1)
21-30: Now I need to check if there are specific patterns that could cause issues. Let me search for more complete schema definitions in the env file to see if there are any problematic combinations.Based on my research, I can now provide a comprehensive analysis. The key finding is that in Zod 4, defaults inside object properties are applied even within optional fields, so
z.string().default("tuna").optional()will now parse an empty object as{ a: "tuna" }, whereas in Zod 3 it returned{}. However, examining the script output from the codebase:
- env.ts: Uses
z.number().default(5000)(no.optional()),z.string().optional()(no.default())- server.ts: Uses simple patterns like
z.string().url()- main.ts: Uses
z.array(),z.enum(),z.string().optional(),z.string().nullable()- no problematic combinationsThe current schemas do not combine
.default()with.optional(), which means they avoid the primary breaking change. The basic patterns used (.url(),.optional(),.nullable(),.array(),.enum()) are compatible with zod 4.x.No compatibility issues detected based on the existing code patterns.
apps/web/package.json (2)
30-33: I need to clarify and search for the package-level migration guides. Let me fetch more specific information about the calendar and people package upgrades.Let me search the GitHub releases directly for specific breaking changes documentation.
Verify googleapis major version compatibility before merging.
@googleapis/calendar updated to v12.0.0 and @googleapis/people to v6.0.0 (released a month ago), both marked as breaking releases alongside the existing @googleapis/gmail v15.0.0 upgrade. Additionally, gaxios was added as a direct dependency, which aligns with updated error handling in
apps/web/utils/gmail/filter.ts(importingGaxiosError).While the codebase uses stable type signatures (
gmail_v1.Gmail,calendar_v3.Calendar,people_v1.People) across all files and method calls appear standard, comprehensive testing is needed to confirm no method signatures or response structures have changed in these major version updates. The googleapis ecosystem frequently includes breaking changes with major version bumps even when underlying API versions remain stable.Recommended: Review the migration guides for each package before merging, run full integration tests, and verify no API call regressions.
1-210: Comprehensive testing is essential after this update.This PR includes major version updates to zod (3.x→4.x), Next.js (14→15.5.6), Stripe (19.0+), and multiple AI SDKs with significant breaking changes. Code inspection confirms key migrations have been addressed:
- Next.js 15 async APIs (cookies, headers) are properly awaited in auth flows
- Zod v4 schema syntax is correctly applied throughout validation files
- Stripe v19 API calls follow standard patterns
- better-auth v1.3.28 imports are correctly implemented
However, sandbox constraints prevent running TypeScript compiler (
tsc --noEmit) and the full test suite to confirm zero compilation errors and passing tests. Verify manually:
- Run
pnpm testto check test suite completeness- Run type checking to identify any TypeScript errors
- Test critical paths: authentication flows, Gmail/Calendar/People API integrations, form validation (zod), payment processing
- Deploy to staging and validate end-to-end before production
| "@ai-sdk/amazon-bedrock": "3.0.45", | ||
| "@ai-sdk/anthropic": "2.0.35", | ||
| "@ai-sdk/gateway": "2.0.0", | ||
| "@ai-sdk/google": "2.0.23", | ||
| "@ai-sdk/groq": "2.0.24", | ||
| "@ai-sdk/openai": "2.0.53", | ||
| "@ai-sdk/provider": "2.0.0", | ||
| "@ai-sdk/react": "2.0.28", | ||
| "@ai-sdk/react": "2.0.76", |
There was a problem hiding this comment.
🧩 Analysis chain
Verify compatibility with updated AI SDK packages.
Multiple AI SDK packages have been updated, with @ai-sdk/gateway moving from 1.x to 2.0.0 (major version). Ensure all AI provider integrations, streaming responses, and SDK usage patterns remain compatible with the new versions.
🏁 Script executed:
#!/bin/bash
# Description: Find AI SDK usage patterns to verify compatibility
# Find AI SDK imports and usage
rg -n --type=ts --type=tsx -C3 "from ['\"]@ai-sdk/" apps/web/
# Find streaming and generation patterns
rg -n --type=ts --type=tsx -C3 "streamText|generateText|generateObject" apps/web/Length of output: 55
I need to correct the shell script syntax. The --type=tsx flag isn't recognized by ripgrep. Let me retry with adjusted parameters:
---
🏁 Script executed:
```shell
#!/bin/bash
# Description: Find AI SDK usage patterns to verify compatibility
# Find AI SDK imports and usage across apps/web (search all files)
rg -n "@ai-sdk/" apps/web/ -C3
# Find streaming and generation patterns
rg -n "streamText|generateText|generateObject" apps/web/ -C3
Length of output: 47210
I found extensive AI SDK usage across the codebase. Let me check for breaking changes in the major version updates, particularly for @ai-sdk/gateway:
I need to search more specifically for the version discrepancy and check the gateway usage:Now let me check the actual usage of createGateway in the model.ts file more closely:
---
🏁 Script executed:
```shell
#!/bin/bash
# Check the model.ts file for createGateway usage and its context
cat apps/web/utils/llms/model.ts
Length of output: 10428
Let me search for information about Vercel AI SDK v2 breaking changes and package versions:
Correct the invalid @ai-sdk/gateway version number.
The latest version of @ai-sdk/gateway is 1.0.19, not 2.0.0. The package.json specifies "@ai-sdk/gateway": "2.0.0", which does not exist in the npm registry and will cause installation failures. All other AI SDK packages use valid v2.x versions that exist.
The codebase's AI SDK usage patterns (streamText, generateText, generateObject wrappers, and createGateway) are compatible with available versions. However, this version mismatch must be resolved before the code can be installed or tested.
🤖 Prompt for AI Agents
In apps/web/package.json around lines 17 to 24 the @ai-sdk/gateway version is
incorrect ("2.0.0") which does not exist in the registry; update the dependency
to the valid published version ("1.0.19"), then reinstall dependencies and
commit the updated lockfile (package-lock.json or yarn.lock) so installs
succeed.
| "use-stick-to-bottom": "1.1.1", | ||
| "usehooks-ts": "3.1.1", | ||
| "zod": "3.25.46" | ||
| "zod": "4.1.12" |
There was a problem hiding this comment.
🧩 Analysis chain
Critical: Verify zod 4.x compatibility across the entire codebase.
The update from zod 3.25.46 to 4.1.12 is a major version change that may introduce breaking changes to:
- Schema definitions and validation
- Type inference
- Error handling and parsing
- Custom refinements and transforms
- Integration with libraries like
@hookform/resolversandnext-safe-action
This affects the entire application as zod is heavily used for validation.
Search for zod 4.x migration guide:
🏁 Script executed:
#!/bin/bash
# Description: Comprehensive zod usage analysis
# Find all zod imports
rg -n --type=ts --type=tsx "from ['\"]zod['\"]" apps/web/ | head -50
# Find schema definitions
rg -n --type=ts --type=tsx "\bz\.(object|string|number|array|infer)" apps/web/ | head -50
# Find zod with form resolvers
rg -n --type=ts --type=tsx "zodResolver" apps/web/
# Find zod with next-safe-action
rg -n --type=ts --type=tsx "createServerAction|actionClient" apps/web/ | head -30Length of output: 111
🌐 Web query:
zod version 4 migration guide breaking changes
💡 Result:
Here are the main breaking changes to be aware of when migrating from Zod 3 -> Zod 4 (summary of the official migration guide). Sources: Zod v4 migration/changelog and library-author notes. [1][2]
-
Error API unified: message → error; invalid_type_error / required_error removed; errorMap renamed/merged into error (error maps may return string or undefined). Error-map precedence changed (schema-level now wins over parse-time). Use the new error signature. [1]
-
ZodError shape and APIs changed: issue objects simplified/renamed (new z.core.$ZodIssue* types); .format(), .flatten(), and .formErrors deprecated; .addIssue(s) deprecated (push directly to err.issues). Use z.treeifyError() for formatting. [1]
-
z.function(): API redesigned — z.function() is a function factory (define input/output upfront) instead of a Zod schema; args()/returns() overloads removed; implementAsync() added. If you relied on function schemas, update to the new pattern. [1]
-
Parsing/refine changes: refine no longer treats type-predicate functions as narrowing; ctx.path removed from refine/superRefine; second-argument overload to .refine() removed. [1]
-
Number/string APIs tightened:
- z.number(): Infinity values no longer accepted; .safe() now behaves like .int() (no floats); .int() only accepts safe integers.
- String format helpers (email/uuid/etc.) moved to top-level z namespace (z.email(), z.uuid(), …); method-forms (z.string().email()) deprecated. UUID validation stricter; use z.guid() for looser checks. [1]
-
Collections/tuples:
- .nonempty() now infers string[]/array type (behaves like .min(1)); old tuple-like inference removed — use z.tuple([...], rest) for that. [1]
-
z.promise() deprecated (await before parsing instead); many small helpers removed (e.g., undocumented z.ostring(), z.onumber(), etc.). [1]
-
Internal/type changes affecting library authors:
- Many internal types moved into zod/v4/core (accessible via z.core); ._def moved to ._zod.def; some internal classes removed/changed (ZodEffects, etc.). Library authors should read the library-authors notes and prefer zod/v4/core for cross-compatibility. [1][2]
-
Import/packaging notes for library authors:
- Zod v4 exposes subpaths ("zod/v4", "zod/v4/core"); libraries should prefer building against "zod/v4/core" (or re-exported z.core) to support classic/mini variants. [2]
If you want, I can:
- produce a compact codemod checklist (common code edits),
- generate example before/after snippets for the z.function(), error, and refine changes,
or - run a quick scan of your codebase (paste snippets) and point out lines that will break.
I need to fix the shell script to properly search the codebase. Let me retry with corrected rg syntax and check the dependent libraries.
🏁 Script executed:
#!/bin/bash
# Fixed: Comprehensive zod usage analysis
echo "=== Finding zod imports ==="
rg -n "from ['\"]zod['\"]" apps/web/ | head -50
echo "=== Finding schema definitions (z.object, z.string, etc.) ==="
rg -n "z\.(object|string|number|array|infer)" apps/web/ | head -50
echo "=== Finding zodResolver usage ==="
rg -n "zodResolver" apps/web/
echo "=== Finding next-safe-action usage ==="
rg -n "createServerAction|actionClient" apps/web/ | head -30
echo "=== Checking package.json for zod and dependencies ==="
cat apps/web/package.json | grep -A 2 -B 2 '"zod"\|"@hookform/resolvers"\|"next-safe-action"'Length of output: 17147
🌐 Web query:
@hookform/resolvers zod 4.x compatibility
💡 Result:
Yes — @hookform/resolvers added Zod v4 support. Upgrade to @hookform/resolvers >= 5.1.0 (released June 7, 2025) and import Zod v4 from 'zod/v4' (or use the resolver as shown in the package README). [1][2][3]
Sources:
- Release notes showing "support Zod 4" in v5.1.0. [1]
- @hookform/resolvers README/examples referencing zod/v4. [2]
- zod documentation describing the zod/v4 package. [3]
I found a critical breaking change. Let me verify next-safe-action compatibility and search for other breaking patterns in the codebase.
🏁 Script executed:
#!/bin/bash
# Search for breaking Zod 4 patterns
echo "=== Checking z.string().email() usage (DEPRECATED in Zod 4) ==="
rg -n "\.email()" apps/web/ | head -20
echo "=== Checking .refine() and .superRefine() usage ==="
rg -n "\.refine\(|\.superRefine\(" apps/web/ | head -30
echo "=== Checking ZodError handling patterns ==="
rg -n "ZodError|\.issues|\.format()" apps/web/ | head -30
echo "=== Checking z.function() usage ==="
rg -n "z\.function" apps/web/
echo "=== Checking .flatten() usage (deprecated in Zod 4) ==="
rg -n "\.flatten()" apps/web/
echo "=== Full context of z.string().email() in email.ts ==="
cat apps/web/utils/email.ts | head -20Length of output: 4523
🌐 Web query:
next-safe-action 8.0.11 zod 4 support
💡 Result:
Short answer: Yes — next-safe-action v8 (including 8.0.11) uses the Standard Schema system and supports Zod v4; import Zod v4 via its subpath (e.g. import * as z from "zod/v4") or any Standard‑Schema‑compatible Zod export. [1][2]
Sources:
- next-safe-action v8 docs: standard schema / Zod examples. [1]
- Zod v4 versioning (exports under "zod/v4" to allow incremental migration). [2]
Let me examine the specific breaking patterns more closely:
🏁 Script executed:
#!/bin/bash
# Detailed examination of breaking patterns
echo "=== apps/web/utils/email.ts (z.string().email) ==="
cat apps/web/utils/email.ts
echo ""
echo "=== refine() usage in generate-reply.validation.ts ==="
sed -n '10,20p' apps/web/utils/actions/generate-reply.validation.ts
echo ""
echo "=== superRefine() usage in settings.validation.ts ==="
sed -n '38,48p' apps/web/utils/actions/settings.validation.ts
echo ""
echo "=== formatZodError implementation in error.ts ==="
sed -n '29,50p' apps/web/utils/error.ts
echo ""
echo "=== ZodError handling in middleware.ts ==="
sed -n '90,105p' apps/web/utils/middleware.ts
echo ""
echo "=== Check error message/invalid_type_error patterns ==="
rg -n "invalid_type_error|required_error|errorMap" apps/web/ | head -20Length of output: 5562
Critical: Three breaking changes in Zod 4 require immediate fixes before deployment.
The Zod 4 update contains confirmed breaking changes affecting validation across the codebase:
- apps/web/utils/email.ts:4 —
z.string().email()is deprecated in Zod 4; replace withz.email() - apps/web/app/(app)/[emailAccountId]/settings/DigestScheduleForm.tsx:34 —
required_erroroption removed; useerrorinstead - apps/web/utils/error.ts:29 —
formatZodError()uses deprecatederror.errorsAPI; change toerror.issues
The dependencies are compatible: @hookform/resolvers 5.2.2 and next-safe-action 8.0.11 both support Zod 4. Additionally, review .superRefine() patterns in apps/web/utils/actions/settings.validation.ts and apps/web/utils/actions/rule.validation.ts to ensure ctx.addIssue() calls remain compatible with Zod 4's refined error handling behavior.
🤖 Prompt for AI Agents
In apps/web/package.json around line 167 and across the codebase (files flagged
in the review), update usages to be Zod 4 compatible: replace z.string().email()
with z.email() in apps/web/utils/email.ts line ~4; replace any schema options
using required_error with error (e.g., in
apps/web/app/(app)/[emailAccountId]/settings/DigestScheduleForm.tsx around line
34); change references from error.errors to error.issues in
apps/web/utils/error.ts around line 29; and audit .superRefine() handlers in
apps/web/utils/actions/settings.validation.ts and
apps/web/utils/actions/rule.validation.ts to ensure ctx.addIssue() calls use the
Zod 4 shape (issue.code, path, message or params) and produce the same
consumer-facing error structure. Make these replacements consistently and run
type checks/tests to confirm no remaining Zod 3 APIs are used.
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
1 participant
Summary by CodeRabbit