Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
WalkthroughThis PR systematically updates API route handlers across the application to register route identifiers with middleware wrappers (withEmailAccount, withAuth, withError, withEmailProvider) and migrates logging from module-scoped loggers to request-scoped loggers. Version bumped to v2.18.24. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Possibly related PRs
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (3)
apps/web/app/api/google/contacts/route.ts (1)
25-36: Add null check for emailAccount before creating client.The database query can return
nullif the email account doesn't exist. While optional chaining prevents a runtime error, passingundefinedtokens togetContactsClientmay cause issues downstream.Apply this diff to add proper validation:
const emailAccount = await prisma.emailAccount.findUnique({ where: { id: emailAccountId }, select: { account: { select: { access_token: true, refresh_token: true, expires_at: true }, }, }, }); + + if (!emailAccount) { + return NextResponse.json( + { error: "Email account not found" }, + { status: 404 }, + ); + } + const client = getContactsClient({ - accessToken: emailAccount?.account.access_token, - refreshToken: emailAccount?.account.refresh_token, + accessToken: emailAccount.account.access_token, + refreshToken: emailAccount.account.refresh_token, });apps/web/app/api/watch/all/route.ts (1)
32-39: Consider adding route identifier to POST handler for consistency.The GET handler was updated with the route identifier "watch/all", but the POST handler was not. Both handlers perform the same
watchAllEmails()operation and would benefit from consistent logging context.Apply this diff to add the route identifier:
-export const POST = withError(async (request) => { +export const POST = withError("watch/all", async (request) => { if (!(await hasPostCronSecret(request))) {apps/web/app/api/google/watch/all/route.ts (1)
142-151: Update POST handler to match GET pattern.The GET handler was updated with a route identifier, but the POST handler was not. For consistency and complete logging coverage, apply the same pattern.
Apply this diff:
-export const POST = withError(async (request) => { +export const POST = withError("google/watch/all", async (request) => { if (!(await hasPostCronSecret(request))) {
🧹 Nitpick comments (7)
apps/web/app/api/user/folders/route.ts (1)
8-20: Consider adding error handling for consistency.For consistency with other routes (e.g.,
apps/web/app/api/labels/route.ts), consider wrapping thegetFolderscall in a try-catch block and usingrequest.logger.error()to log failures. This would better leverage the request-scoped logging infrastructure introduced by this PR.Example pattern:
export const GET = withEmailProvider("user/folders", async (request) => { const emailProvider = request.emailProvider; if (!isMicrosoftProvider(emailProvider.name)) { return NextResponse.json( { error: "Only Microsoft email providers are supported" }, { status: 400 }, ); } + try { const result = await getFolders({ emailProvider }); return NextResponse.json(result); + } catch (error) { + request.logger.error("Error fetching folders", { error }); + return NextResponse.json( + { error: "Failed to fetch folders" }, + { status: 500 }, + ); + } });apps/web/app/api/email-stream/route.ts (1)
40-43: Consider handling subscription failures more gracefully.Currently, if
psubscribefails, the error is logged but the SSE stream is still created and returned to the client, potentially causing the client to wait indefinitely without receiving any messages. Consider returning an error response if the subscription fails to provide clearer feedback.Note: This is a pre-existing behavior pattern, not introduced by this PR.
apps/web/app/api/resend/digest/route.ts (1)
36-40: Consider adding emailAccountId to logger context.The logger is initialized with
force: truebut doesn't include theemailAccountIdin the context. The POST handler (line 63) includes it, and other similar routes (e.g.,resend/summary) typically include the emailAccountId in the logger context for better traceability.Apply this diff to add emailAccountId to the logger context:
const logger = request.logger.with({ + emailAccountId, force: true, });apps/web/app/api/messages/route.ts (1)
32-46: Use a concrete Logger type instead ofanyforloggeringetMessagesSince this function is always called with
request.logger, you can tighten the type by using yourLoggerinterface instead ofany, which improves type safety and editor support.You could apply something like:
-import type { EmailProvider } from "@/utils/email/types"; +import type { EmailProvider } from "@/utils/email/types"; +import type { Logger } from "@/utils/logger"; @@ - logger, + logger, }: { @@ - logger: any; + logger: Logger; }Please confirm the
Loggerimport path matches the one used inapps/web/utils/middleware.tsand adjust if needed. Based on learnings.apps/web/app/api/watch/all/route.ts (1)
8-8: Consider migrating to request-scoped logging.While the GET handler now has route context via the wrapper, the module-scoped logger is still in use. Other files in this PR (e.g.,
labels/route.ts) have migrated torequest.loggerfor better request-specific context. Consider doing the same here for consistency.Also applies to: 18-18
apps/web/app/api/google/watch/all/route.ts (1)
10-10: Consider migrating to request-scoped logger.The PR objectives mention migrating from module-scoped to request-scoped loggers. The middleware provides
request.loggerfor request-scoped logging. Consider replacing the module-scoped logger with request-scoped logging throughout this file for better traceability.apps/web/app/api/user/stats/newsletters/route.ts (1)
16-16: Consider migrating the module-scoped logger to request-scoped logging.While the route identifier has been added, the module-scoped logger on Line 16 is still in use (e.g., Line 225 in
getNewsletterCounts). To fully align with this PR's objective of migrating to request-scoped logging, consider passingrequest.loggeras a parameter to helper functions likegetNewsletterCounts.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (69)
apps/web/app/api/chats/[chatId]/route.ts(1 hunks)apps/web/app/api/chats/route.ts(1 hunks)apps/web/app/api/clean/history/route.ts(1 hunks)apps/web/app/api/email-stream/route.ts(7 hunks)apps/web/app/api/google/calendar/auth-url/route.ts(1 hunks)apps/web/app/api/google/contacts/route.ts(1 hunks)apps/web/app/api/google/linking/auth-url/route.ts(1 hunks)apps/web/app/api/google/watch/all/route.ts(1 hunks)apps/web/app/api/google/watch/route.ts(2 hunks)apps/web/app/api/knowledge/route.ts(1 hunks)apps/web/app/api/labels/route.ts(2 hunks)apps/web/app/api/mcp/[integration]/auth-url/route.ts(1 hunks)apps/web/app/api/mcp/integrations/route.ts(1 hunks)apps/web/app/api/messages/attachment/route.ts(1 hunks)apps/web/app/api/messages/batch/route.ts(1 hunks)apps/web/app/api/messages/route.ts(3 hunks)apps/web/app/api/organizations/[organizationId]/executed-rules-count/route.ts(1 hunks)apps/web/app/api/organizations/[organizationId]/members/route.ts(1 hunks)apps/web/app/api/outlook/linking/auth-url/route.ts(1 hunks)apps/web/app/api/outlook/watch/route.ts(3 hunks)apps/web/app/api/referrals/code/route.ts(1 hunks)apps/web/app/api/referrals/stats/route.ts(1 hunks)apps/web/app/api/resend/digest/route.ts(1 hunks)apps/web/app/api/resend/summary/route.ts(1 hunks)apps/web/app/api/sso/signin/route.ts(2 hunks)apps/web/app/api/stripe/success/route.ts(1 hunks)apps/web/app/api/threads/[id]/route.ts(1 hunks)apps/web/app/api/threads/basic/route.ts(2 hunks)apps/web/app/api/threads/batch/route.ts(3 hunks)apps/web/app/api/threads/route.ts(2 hunks)apps/web/app/api/unsubscribe/route.ts(3 hunks)apps/web/app/api/user/api-keys/route.ts(1 hunks)apps/web/app/api/user/calendars/route.ts(1 hunks)apps/web/app/api/user/categories/route.ts(1 hunks)apps/web/app/api/user/categorization-preferences/route.ts(1 hunks)apps/web/app/api/user/categorize/senders/progress/route.ts(1 hunks)apps/web/app/api/user/categorize/senders/uncategorized/route.ts(1 hunks)apps/web/app/api/user/cold-email/route.ts(1 hunks)apps/web/app/api/user/digest-schedule/route.ts(1 hunks)apps/web/app/api/user/digest-settings/route.ts(1 hunks)apps/web/app/api/user/draft-actions/route.ts(1 hunks)apps/web/app/api/user/email-accounts/route.ts(1 hunks)apps/web/app/api/user/executed-rules/batch/route.ts(1 hunks)apps/web/app/api/user/executed-rules/history/route.ts(2 hunks)apps/web/app/api/user/folders/route.ts(1 hunks)apps/web/app/api/user/group/[groupId]/items/route.ts(1 hunks)apps/web/app/api/user/group/[groupId]/messages/route.ts(1 hunks)apps/web/app/api/user/group/[groupId]/rules/route.ts(1 hunks)apps/web/app/api/user/group/route.ts(1 hunks)apps/web/app/api/user/labels/route.ts(1 hunks)apps/web/app/api/user/me/route.ts(1 hunks)apps/web/app/api/user/no-reply/route.ts(1 hunks)apps/web/app/api/user/persona/route.ts(1 hunks)apps/web/app/api/user/rules/[id]/example/route.ts(1 hunks)apps/web/app/api/user/rules/[id]/route.ts(1 hunks)apps/web/app/api/user/rules/prompt/route.ts(1 hunks)apps/web/app/api/user/rules/route.ts(1 hunks)apps/web/app/api/user/settings/multi-account/route.ts(1 hunks)apps/web/app/api/user/setup-progress/route.ts(1 hunks)apps/web/app/api/user/stats/day/route.ts(1 hunks)apps/web/app/api/user/stats/newsletters/route.ts(1 hunks)apps/web/app/api/user/stats/recipients/route.ts(1 hunks)apps/web/app/api/user/stats/route.ts(1 hunks)apps/web/app/api/user/stats/sender-emails/route.ts(1 hunks)apps/web/app/api/user/stats/senders/route.ts(1 hunks)apps/web/app/api/watch/all/route.ts(1 hunks)apps/web/app/api/watch/route.ts(1 hunks)apps/web/utils/middleware.ts(3 hunks)version.txt(1 hunks)
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-07-17T04:19:57.099Z
Learnt from: edulelis
Repo: elie222/inbox-zero PR: 576
File: packages/resend/emails/digest.tsx:78-83
Timestamp: 2025-07-17T04:19:57.099Z
Learning: In packages/resend/emails/digest.tsx, the DigestEmailProps type uses `[key: string]: DigestItem[] | undefined | string | Date | undefined` instead of intersection types like `& Record<string, DigestItem[] | undefined>` due to implementation constraints. This was the initial implementation approach and cannot be changed to more restrictive typing.
Applied to files:
apps/web/app/api/resend/digest/route.tsapps/web/app/api/user/digest-schedule/route.tsapps/web/app/api/user/digest-settings/route.ts
📚 Learning: 2025-07-08T13:14:03.250Z
Learnt from: elie222
Repo: elie222/inbox-zero PR: 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.
Applied to files:
apps/web/utils/middleware.ts
🧬 Code graph analysis (66)
apps/web/app/api/outlook/linking/auth-url/route.ts (2)
apps/web/app/api/google/linking/auth-url/route.ts (1)
GET(28-41)apps/web/utils/middleware.ts (1)
withAuth(354-362)
apps/web/app/api/resend/digest/route.ts (3)
apps/web/app/api/chats/[chatId]/route.ts (1)
GET(7-24)apps/web/app/api/resend/summary/route.ts (1)
GET(254-263)apps/web/utils/middleware.ts (1)
withEmailAccount(374-392)
apps/web/app/api/user/stats/day/route.ts (3)
apps/web/app/api/labels/route.ts (1)
GET(23-42)apps/web/app/api/user/rules/[id]/example/route.ts (1)
GET(36-49)apps/web/utils/middleware.ts (1)
withEmailProvider(402-415)
apps/web/app/api/user/stats/senders/route.ts (1)
apps/web/utils/middleware.ts (1)
withEmailAccount(374-392)
apps/web/app/api/stripe/success/route.ts (2)
apps/web/app/api/email-stream/route.ts (1)
GET(11-113)apps/web/utils/middleware.ts (1)
withAuth(354-362)
apps/web/app/api/user/rules/prompt/route.ts (1)
apps/web/utils/middleware.ts (1)
withEmailAccount(374-392)
apps/web/app/api/user/me/route.ts (2)
apps/web/app/api/google/watch/all/route.ts (1)
GET(131-140)apps/web/utils/middleware.ts (1)
withError(328-346)
apps/web/app/api/user/digest-schedule/route.ts (1)
apps/web/utils/middleware.ts (1)
withEmailAccount(374-392)
apps/web/app/api/user/no-reply/route.ts (1)
apps/web/utils/middleware.ts (1)
withEmailProvider(402-415)
apps/web/app/api/user/labels/route.ts (2)
apps/web/app/api/chats/[chatId]/route.ts (1)
GET(7-24)apps/web/utils/middleware.ts (1)
withEmailAccount(374-392)
apps/web/app/api/user/rules/[id]/example/route.ts (2)
apps/web/app/api/labels/route.ts (1)
GET(23-42)apps/web/utils/middleware.ts (1)
withEmailProvider(402-415)
apps/web/app/api/google/contacts/route.ts (2)
apps/web/app/api/chats/[chatId]/route.ts (1)
GET(7-24)apps/web/utils/middleware.ts (1)
withEmailAccount(374-392)
apps/web/app/api/user/executed-rules/batch/route.ts (1)
apps/web/utils/middleware.ts (1)
withEmailAccount(374-392)
apps/web/app/api/user/stats/recipients/route.ts (2)
apps/web/app/api/chats/[chatId]/route.ts (1)
GET(7-24)apps/web/utils/middleware.ts (1)
withEmailAccount(374-392)
apps/web/app/api/messages/attachment/route.ts (4)
apps/web/app/api/labels/route.ts (1)
GET(23-42)apps/web/app/api/messages/batch/route.ts (1)
GET(33-51)apps/web/app/api/messages/route.ts (1)
GET(11-30)apps/web/utils/middleware.ts (1)
withEmailProvider(402-415)
apps/web/app/api/user/categorization-preferences/route.ts (1)
apps/web/utils/middleware.ts (1)
withEmailProvider(402-415)
apps/web/app/api/watch/all/route.ts (2)
apps/web/app/api/google/watch/all/route.ts (1)
GET(131-140)apps/web/utils/middleware.ts (1)
withError(328-346)
apps/web/app/api/google/watch/all/route.ts (2)
apps/web/app/api/outlook/watch/all/route.ts (1)
GET(122-131)apps/web/utils/middleware.ts (1)
withError(328-346)
apps/web/app/api/organizations/[organizationId]/members/route.ts (3)
apps/web/app/api/organizations/[organizationId]/executed-rules-count/route.ts (1)
GET(10-22)apps/web/utils/middleware.ts (1)
withAuth(354-362)apps/web/utils/organizations/access.ts (1)
fetchAndCheckIsAdmin(60-82)
apps/web/app/api/google/linking/auth-url/route.ts (2)
apps/web/app/api/outlook/linking/auth-url/route.ts (1)
GET(21-36)apps/web/utils/middleware.ts (1)
withAuth(354-362)
apps/web/app/api/user/draft-actions/route.ts (1)
apps/web/utils/middleware.ts (1)
withEmailAccount(374-392)
apps/web/app/api/mcp/[integration]/auth-url/route.ts (6)
apps/web/app/api/chats/[chatId]/route.ts (1)
GET(7-24)apps/web/app/api/google/calendar/auth-url/route.ts (1)
GET(31-48)apps/web/app/api/google/linking/auth-url/route.ts (1)
GET(28-41)apps/web/utils/middleware.ts (1)
withEmailAccount(374-392)apps/web/utils/oauth/state.ts (5)
generateOAuthState(10-18)getMcpOAuthStateType(48-49)getMcpStateCookieName(42-43)oauthStateCookieOptions(34-40)getMcpPkceCookieName(45-46)apps/web/utils/mcp/oauth.ts (1)
generateOAuthUrl(30-75)
apps/web/app/api/chats/route.ts (2)
apps/web/app/api/chats/[chatId]/route.ts (1)
GET(7-24)apps/web/utils/middleware.ts (1)
withEmailAccount(374-392)
apps/web/app/api/user/stats/newsletters/route.ts (6)
apps/web/app/api/messages/batch/route.ts (1)
GET(33-51)apps/web/app/api/messages/route.ts (1)
GET(11-30)apps/web/app/api/threads/[id]/route.ts (1)
GET(28-55)apps/web/app/api/threads/route.ts (1)
GET(13-54)apps/web/app/api/user/stats/sender-emails/route.ts (1)
GET(72-93)apps/web/utils/middleware.ts (1)
withEmailProvider(402-415)
apps/web/app/api/threads/batch/route.ts (4)
apps/web/app/api/labels/route.ts (1)
GET(23-42)apps/web/app/api/messages/batch/route.ts (1)
GET(33-51)apps/web/app/api/messages/route.ts (1)
GET(11-30)apps/web/utils/middleware.ts (1)
withEmailProvider(402-415)
apps/web/app/api/user/rules/route.ts (2)
apps/web/app/api/user/rules/[id]/route.ts (1)
GET(50-62)apps/web/utils/middleware.ts (1)
withEmailAccount(374-392)
apps/web/app/api/organizations/[organizationId]/executed-rules-count/route.ts (2)
apps/web/app/api/organizations/[organizationId]/members/route.ts (1)
GET(10-29)apps/web/utils/middleware.ts (1)
withAuth(354-362)
apps/web/app/api/user/group/[groupId]/items/route.ts (2)
apps/web/app/api/chats/[chatId]/route.ts (1)
GET(7-24)apps/web/utils/middleware.ts (1)
withEmailAccount(374-392)
apps/web/app/api/google/watch/route.ts (6)
apps/web/app/api/chats/[chatId]/route.ts (1)
GET(7-24)apps/web/app/api/email-stream/route.ts (1)
GET(11-113)apps/web/app/api/google/linking/auth-url/route.ts (1)
GET(28-41)apps/web/app/api/google/watch/all/route.ts (1)
GET(131-140)apps/web/app/api/labels/route.ts (1)
GET(23-42)apps/web/utils/middleware.ts (1)
withAuth(354-362)
apps/web/app/api/clean/history/route.ts (3)
apps/web/app/api/chats/[chatId]/route.ts (1)
GET(7-24)apps/web/app/api/chats/route.ts (1)
GET(7-11)apps/web/utils/middleware.ts (1)
withEmailAccount(374-392)
apps/web/app/api/knowledge/route.ts (2)
apps/web/app/api/chats/[chatId]/route.ts (1)
GET(7-24)apps/web/utils/middleware.ts (1)
withEmailAccount(374-392)
apps/web/app/api/user/categorize/senders/uncategorized/route.ts (3)
apps/web/app/api/chats/[chatId]/route.ts (1)
GET(7-24)apps/web/app/api/google/calendar/auth-url/route.ts (1)
GET(31-48)apps/web/utils/middleware.ts (1)
withEmailAccount(374-392)
apps/web/app/api/watch/route.ts (2)
apps/web/app/api/email-stream/route.ts (1)
GET(11-113)apps/web/utils/middleware.ts (1)
withAuth(354-362)
apps/web/app/api/threads/basic/route.ts (3)
apps/web/app/api/labels/route.ts (1)
GET(23-42)apps/web/app/api/messages/route.ts (1)
GET(11-30)apps/web/utils/middleware.ts (1)
withEmailProvider(402-415)
apps/web/app/api/user/categorize/senders/progress/route.ts (1)
apps/web/utils/middleware.ts (1)
withEmailAccount(374-392)
apps/web/app/api/outlook/watch/route.ts (3)
apps/web/app/api/email-stream/route.ts (1)
GET(11-113)apps/web/app/api/google/watch/route.ts (1)
GET(9-68)apps/web/app/api/outlook/watch/all/route.ts (1)
GET(122-131)
apps/web/app/api/chats/[chatId]/route.ts (2)
apps/web/app/api/chats/route.ts (1)
GET(7-11)apps/web/utils/middleware.ts (1)
withEmailAccount(374-392)
apps/web/app/api/email-stream/route.ts (2)
apps/web/app/api/google/linking/auth-url/route.ts (1)
GET(28-41)apps/web/app/api/google/watch/route.ts (1)
GET(9-68)
apps/web/app/api/user/persona/route.ts (1)
apps/web/utils/middleware.ts (1)
withEmailAccount(374-392)
apps/web/app/api/user/setup-progress/route.ts (1)
apps/web/utils/middleware.ts (1)
withEmailAccount(374-392)
apps/web/app/api/user/group/[groupId]/rules/route.ts (2)
apps/web/app/api/chats/[chatId]/route.ts (1)
GET(7-24)apps/web/utils/middleware.ts (1)
withEmailAccount(374-392)
apps/web/app/api/user/stats/sender-emails/route.ts (2)
apps/web/app/api/chats/[chatId]/route.ts (1)
GET(7-24)apps/web/utils/middleware.ts (1)
withEmailAccount(374-392)
apps/web/app/api/sso/signin/route.ts (2)
apps/web/app/api/email-stream/route.ts (1)
GET(11-113)apps/web/utils/middleware.ts (1)
withError(328-346)
apps/web/app/api/resend/summary/route.ts (3)
apps/web/app/api/email-stream/route.ts (1)
GET(11-113)apps/web/app/api/resend/digest/route.ts (1)
GET(32-45)apps/web/utils/middleware.ts (1)
withEmailAccount(374-392)
apps/web/app/api/google/calendar/auth-url/route.ts (3)
apps/web/utils/middleware.ts (1)
withEmailAccount(374-392)apps/web/utils/calendar/constants.ts (1)
CALENDAR_STATE_COOKIE_NAME(1-1)apps/web/utils/oauth/state.ts (1)
oauthStateCookieOptions(34-40)
apps/web/app/api/user/folders/route.ts (2)
apps/web/app/api/labels/route.ts (1)
GET(23-42)apps/web/app/api/messages/attachment/route.ts (1)
GET(5-36)
apps/web/app/api/threads/[id]/route.ts (4)
apps/web/app/api/email-stream/route.ts (1)
GET(11-113)apps/web/app/api/labels/route.ts (1)
GET(23-42)apps/web/app/api/threads/route.ts (1)
GET(13-54)apps/web/utils/middleware.ts (1)
withEmailProvider(402-415)
apps/web/app/api/user/api-keys/route.ts (1)
apps/web/utils/middleware.ts (1)
withAuth(354-362)
apps/web/app/api/user/email-accounts/route.ts (1)
apps/web/utils/middleware.ts (1)
withAuth(354-362)
apps/web/app/api/referrals/stats/route.ts (1)
apps/web/utils/middleware.ts (1)
withAuth(354-362)
apps/web/app/api/labels/route.ts (1)
apps/web/utils/middleware.ts (1)
withEmailProvider(402-415)
apps/web/app/api/user/group/route.ts (1)
apps/web/utils/middleware.ts (1)
withEmailAccount(374-392)
apps/web/app/api/messages/batch/route.ts (2)
apps/web/app/api/messages/route.ts (1)
GET(11-30)apps/web/utils/middleware.ts (1)
withEmailProvider(402-415)
apps/web/app/api/user/stats/route.ts (1)
apps/web/utils/middleware.ts (1)
withEmailProvider(402-415)
apps/web/app/api/referrals/code/route.ts (1)
apps/web/utils/middleware.ts (1)
withAuth(354-362)
apps/web/app/api/threads/route.ts (3)
apps/web/app/api/messages/route.ts (1)
GET(11-30)apps/web/app/api/threads/[id]/route.ts (1)
GET(28-55)apps/web/utils/middleware.ts (1)
withEmailProvider(402-415)
apps/web/app/api/user/group/[groupId]/messages/route.ts (2)
apps/web/utils/middleware.ts (1)
withEmailProvider(402-415)apps/web/app/api/user/group/[groupId]/messages/controller.ts (1)
getGroupEmails(23-59)
apps/web/app/api/user/digest-settings/route.ts (2)
apps/web/app/api/chats/[chatId]/route.ts (1)
GET(7-24)apps/web/utils/middleware.ts (1)
withEmailAccount(374-392)
apps/web/app/api/user/cold-email/route.ts (2)
apps/web/app/api/chats/[chatId]/route.ts (1)
GET(7-24)apps/web/utils/middleware.ts (1)
withEmailAccount(374-392)
apps/web/app/api/user/executed-rules/history/route.ts (3)
apps/web/app/api/messages/route.ts (1)
GET(11-30)apps/web/utils/middleware.ts (1)
withEmailProvider(402-415)apps/web/utils/logger.ts (1)
Logger(5-5)
apps/web/app/api/user/rules/[id]/route.ts (2)
apps/web/app/api/chats/[chatId]/route.ts (1)
GET(7-24)apps/web/app/api/user/rules/route.ts (1)
GET(18-22)
apps/web/app/api/user/calendars/route.ts (2)
apps/web/app/api/google/calendar/auth-url/route.ts (1)
GET(31-48)apps/web/utils/middleware.ts (1)
withEmailAccount(374-392)
apps/web/app/api/user/categories/route.ts (3)
apps/web/app/api/chats/[chatId]/route.ts (1)
GET(7-24)apps/web/app/api/chats/route.ts (1)
GET(7-11)apps/web/utils/middleware.ts (1)
withEmailAccount(374-392)
apps/web/app/api/mcp/integrations/route.ts (2)
apps/web/app/api/chats/[chatId]/route.ts (1)
GET(7-24)apps/web/utils/middleware.ts (1)
withEmailAccount(374-392)
apps/web/app/api/user/settings/multi-account/route.ts (1)
apps/web/utils/middleware.ts (1)
withAuth(354-362)
apps/web/app/api/unsubscribe/route.ts (3)
apps/web/app/api/chats/[chatId]/route.ts (1)
GET(7-24)apps/web/app/api/resend/digest/route.ts (2)
GET(32-45)POST(47-79)apps/web/utils/middleware.ts (2)
withError(328-346)RequestWithLogger(26-28)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
- GitHub Check: cubic · AI code reviewer
- GitHub Check: Jit Security
- GitHub Check: test
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (86)
version.txt (1)
1-1: Version bump is appropriate for this release.The patch version increment (v2.18.23 → v2.18.24) is semantically correct for a maintenance release focused on logging improvements and refactoring without breaking changes.
apps/web/app/api/outlook/linking/auth-url/route.ts (1)
21-21: LGTM! Route identifier added for improved observability.The addition of the route identifier
"outlook/linking/auth-url"to thewithAuthwrapper aligns with the PR objective of better API call logging. This change follows the established pattern shown in the Google linking route and enables request-scoped tracking without altering the handler logic.apps/web/app/api/user/api-keys/route.ts (1)
20-20: LGTM! Route identifier correctly added for logging.The addition of the
"user/api-keys"route identifier to thewithAuthwrapper correctly implements the PR objective of improving API call logging. The identifier accurately reflects the endpoint path and follows the consistent pattern applied across the application.apps/web/app/api/messages/batch/route.ts (1)
33-33: LGTM! Route identifier enhances logging.The addition of the "messages/batch" route identifier to the
withEmailProviderwrapper aligns with the PR objective of improving API call logging. The route identifier correctly corresponds to the API path and follows the same pattern as other routes (e.g., "messages" inapps/web/app/api/messages/route.ts).apps/web/app/api/user/categories/route.ts (1)
12-12: LGTM! Route identifier added for better observability.The addition of the
"user/categories"scope parameter enables request-scoped logging while preserving the handler logic. The identifier correctly reflects the route path and follows the established pattern across the codebase.apps/web/app/api/google/linking/auth-url/route.ts (1)
28-28: LGTM! Route identifier correctly added for improved logging.The route identifier string "google/linking/auth-url" accurately matches the endpoint path and follows the established pattern used across other routes (e.g., outlook/linking/auth-url). This change enhances API call observability without altering functionality.
apps/web/app/api/user/settings/multi-account/route.ts (1)
28-28: LGTM! Route identifier correctly added for improved logging.The route identifier
"user/settings/multi-account"accurately reflects the route path and follows the established pattern shown in the middleware implementation. This change aligns with the PR's objective of better API call logging.apps/web/app/api/stripe/success/route.ts (1)
8-8: LGTM! Route identifier added for better observability.The addition of the route identifier "stripe/success" to the
withAuthwrapper aligns perfectly with the PR objective of improving API call logging. This enables request-scoped logging and better tracing without affecting the handler logic.apps/web/app/api/user/categorize/senders/progress/route.ts (1)
18-25: LGTM! Route identifier correctly registered.The addition of the route scope
"user/categorize/senders/progress"to thewithEmailAccountwrapper aligns with the PR objective of better API call logging. The route identifier correctly matches the file path structure, and the handler logic remains unchanged.apps/web/app/api/user/stats/route.ts (1)
73-73: LGTM! Proper route scoping for improved observability.The addition of the route identifier
"user/stats"enhances logging and traceability while maintaining existing functionality. The identifier appropriately matches the API route path.apps/web/app/api/user/categorization-preferences/route.ts (1)
33-40: LGTM! Route identifier added for better logging.The addition of the route identifier
"user/categorization-preferences"to thewithEmailProviderwrapper is correct and aligns with the PR objective of improving API call logging. The handler logic remains unchanged and the route identifier follows a consistent naming pattern based on the file path.apps/web/app/api/user/draft-actions/route.ts (1)
8-8: LGTM! Good enhancement for observability.The addition of the route scope identifier to
withEmailAccountimproves logging and monitoring capabilities without affecting the handler logic. The scope string follows a clear naming pattern that corresponds to the route structure.apps/web/app/api/google/calendar/auth-url/route.ts (1)
31-48: LGTM! Route identifier correctly added for improved logging.The addition of the
"google/calendar/auth-url"route identifier as the first parameter towithEmailAccountis correct and aligns with the PR objective of better API call logging. The route identifier matches the API path convention, and the handler logic remains functionally unchanged.apps/web/app/api/google/contacts/route.ts (1)
19-19: LGTM: Route identifier added for better logging.The route identifier
"google/contacts"correctly identifies this endpoint for middleware logging and tracing.apps/web/app/api/threads/batch/route.ts (1)
13-13: LGTM! Clean migration to request-scoped logging.The changes successfully migrate this route to the improved logging pattern:
- Adding the route identifier
"threads/batch"enables better observability in logs and monitoring- Using
request.loggerprovides automatic request context instead of the global logger- Error handling remains robust with appropriate context (threadId, emailAccountId)
This is consistent with the logging migration pattern applied across other route handlers in this PR.
Also applies to: 40-40, 52-55
apps/web/app/api/user/executed-rules/batch/route.ts (1)
48-68: LGTM! Route identifier correctly added for logging.The addition of the route identifier
"user/executed-rules/batch"to thewithEmailAccountwrapper correctly implements the PR's logging improvement objective. The identifier matches the API route path, and the handler logic remains unchanged.apps/web/app/api/user/executed-rules/history/route.ts (4)
8-8: LGTM! Type import added for request-scoped logger.The type-only import is correct and supports the migration from module-scoped to request-scoped logging.
18-37: LGTM! GET handler properly updated with route identifier and request-scoped logger.The route identifier "user/executed-rules/history" correctly matches the file path, and the logger is properly passed from
request.loggerto the core function. This change improves request traceability and aligns with the PR's logging enhancement objectives.
39-51: LGTM! Function signature updated to accept request-scoped logger.The signature change is safe since
getExecutedRulesis a private function only used within this file. The logger parameter enables proper request-scoped logging throughout the execution path.
107-110: LGTM! Proper error logging with request-scoped logger.The logger is appropriately used in the error handler with good context (error and messageId). Request-scoped logging improves traceability by allowing correlation of all logs within a single request.
apps/web/app/api/user/folders/route.ts (1)
8-8: LGTM! Route identifier correctly added.The route identifier "user/folders" correctly matches the API route path and aligns with the PR's objective of enabling better API call logging through request-scoped identifiers.
apps/web/app/api/email-stream/route.ts (2)
11-11: LGTM! Route identifier registration is correct.The addition of the
"email-stream"identifier to thewithAuthwrapper aligns with the middleware pattern and improves request tracing by explicitly associating this handler with its route scope.
18-20: Excellent logging migration to request-scoped logger.The consistent migration from module-scoped
loggertorequest.loggeracross all logging points properly associates log entries with request context, significantly improving observability and debugging capabilities without altering the underlying logic or error handling.Also applies to: 32-35, 41-42, 54-54, 67-69, 90-90, 99-101
apps/web/app/api/mcp/[integration]/auth-url/route.ts (5)
17-19: LGTM! Route identifier added for better observability.The route wrapper now includes the identifier "mcp/auth-url" which enables better API call logging as per the PR objectives. The pattern matches other routes updated in this PR.
20-22: Correct handling of async params for Next.js 15.The code properly awaits
paramsbefore destructuring, which is required in Next.js 15 where route params are asynchronous.
24-26: Excellent use of request-scoped logging.The logger is properly configured with integration context via
request.logger.with({ integration }), which ensures all subsequent logs from this handler will include the integration identifier. This aligns with the PR's goal of better API call logging.
28-36: Proper validation with clear error messages.The integration existence and OAuth support checks are correctly implemented with appropriate SafeError exceptions for user-facing error messages.
38-72: Secure OAuth flow implementation with proper error handling.The OAuth flow is correctly implemented with:
- Proper state generation including userId, emailAccountId, and type
- Secure cookie options (httpOnly, secure, sameSite) for state and PKCE verifier
- Appropriate 10-minute expiry for OAuth state
- Good error handling with request-scoped logging before throwing user-facing errors
apps/web/app/api/user/rules/route.ts (1)
18-18: LGTM! Route identifier enhances observability.The addition of the "user/rules" route identifier to the middleware wrapper improves logging and tracing capabilities while preserving the existing handler logic.
apps/web/app/api/user/digest-schedule/route.ts (1)
9-9: LGTM! Consistent route identifier addition.The "user/digest-schedule" identifier properly scopes the middleware for enhanced logging while maintaining existing functionality.
apps/web/app/api/chats/route.ts (1)
7-7: LGTM! Route scoping applied correctly.The "chats" route identifier aligns with the file path and enhances request traceability.
apps/web/app/api/user/digest-settings/route.ts (1)
24-24: LGTM! Route identifier applied consistently.The "user/digest-settings" identifier follows the established pattern and improves logging granularity.
apps/web/app/api/knowledge/route.ts (1)
10-10: LGTM! Clean route identifier addition.The "knowledge" identifier is concise and properly scopes this API endpoint for logging purposes.
apps/web/app/api/clean/history/route.ts (1)
16-16: LGTM! Hierarchical route identifier applied correctly.The "clean/history" identifier accurately reflects the nested route structure and enhances request tracking.
apps/web/app/api/watch/route.ts (1)
8-8: LGTM! Route identifier applied to withAuth wrapper.The "watch" identifier extends the logging pattern to the withAuth middleware consistently.
apps/web/app/api/user/me/route.ts (1)
68-68: LGTM! Route identifier applied to withError wrapper.The "user/me" identifier completes the logging pattern across different middleware types (withEmailAccount, withAuth, withError) while preserving the intentional authentication behavior explained in the comment above.
apps/web/app/api/user/no-reply/route.ts (1)
48-48: LGTM! Route identifier added correctly.The wrapper signature update follows the established pattern, providing a descriptive route scope for better API call logging.
apps/web/app/api/organizations/[organizationId]/members/route.ts (1)
10-29: LGTM! Route identifier added correctly.The wrapper signature update follows the established pattern, providing a descriptive route scope for better API call logging. The handler logic, including authorization checks, remains unchanged.
apps/web/app/api/user/group/[groupId]/messages/route.ts (1)
5-24: LGTM! Route identifier added correctly.The wrapper signature update follows the established pattern, providing a descriptive route scope for better API call logging.
apps/web/app/api/user/stats/sender-emails/route.ts (1)
72-93: LGTM! Route identifier added correctly.The wrapper signature update follows the established pattern, providing a descriptive route scope for better API call logging.
apps/web/app/api/resend/digest/route.ts (1)
32-32: LGTM! Route identifier added correctly.The wrapper signature update follows the established pattern, providing a descriptive route scope for better API call logging.
apps/web/app/api/user/group/route.ts (1)
20-20: LGTM! Route identifier added correctly.The wrapper signature update follows the established pattern, providing a descriptive route scope for better API call logging.
apps/web/app/api/user/group/[groupId]/rules/route.ts (1)
31-43: LGTM! Route identifier added correctly.The wrapper signature update follows the established pattern, providing a descriptive route scope for better API call logging.
apps/web/app/api/threads/[id]/route.ts (1)
28-55: LGTM! Route identifier added and logging migrated correctly.The wrapper signature update follows the established pattern, and the migration from module-scoped to request-scoped logging (line 44) aligns with the PR's objective of better API call logging.
apps/web/app/api/threads/basic/route.ts (1)
13-13: Scoped email provider + per-request error logging look goodUsing
withEmailProvider("threads/basic", ...)and logging viarequest.logger.errorwithemailAccountIdmatches the new middleware pattern and improves observability without changing behavior.Also applies to: 31-34
apps/web/app/api/outlook/watch/route.ts (1)
8-8: Outlook watch now correctly uses scoped auth and structured per-account logging
withAuth("outlook/watch", ...)plus the newrequest.logger.warn/errorcalls (includingemailAccountIdand error details) make this route consistent with the rest of the API and improve diagnosability of account-specific issues.Also applies to: 45-45, 64-66, 74-77
apps/web/app/api/messages/route.ts (1)
11-11: Messages GET correctly wires email provider and request loggerThe
withEmailProvider("messages", ...)wrapper and passingrequest.loggerintogetMessagesare consistent with the new middleware pattern and ensure downstream logging stays request-scoped.Also applies to: 20-27
apps/web/utils/middleware.ts (1)
26-28: RequestWithLogger export, withError typings, and error type guard look consistent and type-safeExporting
RequestWithLogger, threading it through the scopedwithErroroverload, and tighteningisErrorWithConfigAndHeadersto useRecord<string, unknown>all align well with the logging middleware design and remove unnecessaryanyusage; I don’t see further changes needed here. Based on learnings.Also applies to: 319-346, 417-425
apps/web/app/api/referrals/code/route.ts (1)
9-13: Scoped withAuth usage for referrals route is consistentWrapping GET with
withAuth("referrals/code", ...)matches the new route-scoped middleware pattern and keeps the existing handler logic unchanged.apps/web/app/api/user/setup-progress/route.ts (1)
11-16: LGTM! Route identifier correctly added.The route identifier "user/setup-progress" accurately reflects the file path and aligns with the PR's objective of improving API call logging through route-scoped context.
apps/web/app/api/referrals/stats/route.ts (1)
31-35: LGTM! Route identifier correctly added.The route identifier "referrals/stats" accurately reflects the file path and follows the established pattern for improved logging context.
apps/web/app/api/user/stats/day/route.ts (1)
96-112: LGTM! Route identifier correctly added.The route identifier "user/stats/day" accurately reflects the file path and maintains consistency with the PR's logging improvements.
apps/web/app/api/labels/route.ts (1)
23-42: LGTM! Route identifier and request-scoped logging correctly implemented.Two improvements here:
- Route identifier "labels" added for better API call logging
- Migration from module-scoped logger to
request.loggerprovides better context for error trackingBoth changes align well with the PR objectives.
apps/web/app/api/user/persona/route.ts (1)
8-13: LGTM! Route identifier correctly added.The route identifier "user/persona" accurately reflects the file path and follows the established pattern for improved API call logging.
apps/web/app/api/watch/all/route.ts (1)
23-30: LGTM on GET handler route identifier.The route identifier "watch/all" is correctly added to the GET handler.
apps/web/app/api/messages/attachment/route.ts (1)
5-36: LGTM! Route identifier correctly added.The route identifier "messages/attachment" accurately reflects the file path and follows the established pattern for improved API call logging.
apps/web/app/api/chats/[chatId]/route.ts (1)
7-24: LGTM! Route identifier correctly added.The route identifier "chats/detail" is well-chosen for this dynamic route. Using "detail" distinguishes it from the list endpoint while avoiding the parameterized path segment in the identifier.
apps/web/app/api/user/cold-email/route.ts (1)
44-44: LGTM! Route identifier added for better logging context.The addition of the "user/cold-email" route identifier to the
withEmailAccountwrapper aligns with the PR's objective of improving API call logging by providing route context to the middleware.apps/web/app/api/threads/route.ts (2)
13-13: LGTM! Route identifier added for better logging context.The addition of the "threads" route identifier to the
withEmailProviderwrapper enables better API call logging by providing route context.
48-48: LGTM! Migrated to request-scoped logging.The migration from a module-scoped logger to
request.loggerprovides better request context and aligns with the PR's logging improvements.apps/web/app/api/mcp/integrations/route.ts (1)
8-8: LGTM! Route identifier added for better logging context.The addition of the "mcp/integrations" route identifier follows the established pattern across the PR.
apps/web/app/api/resend/summary/route.ts (3)
254-254: LGTM! Route identifier added for better logging context.The addition of the "resend/summary" route identifier to the GET handler aligns with the PR pattern.
258-258: LGTM! Migrated to request-scoped logging.The GET handler now uses
request.loggerfor request-scoped logging context.
265-267: Verify: Inconsistent logging approach between GET and POST handlers.The GET handler (line 254-258) migrated to request-scoped logging using
request.logger, but the POST handler continues to usecreateScopedLogger("resend/summary")at line 266. This inconsistency may be intentional since POST is a cron endpoint withhasCronSecretvalidation, or it may be an oversight in the logging migration.Should the POST handler also migrate to request-scoped logging for consistency, or is the module-scoped logger intentional for cron endpoints?
apps/web/app/api/organizations/[organizationId]/executed-rules-count/route.ts (1)
10-22: LGTM! Route identifier added for better logging context.The addition of the "organizations/executed-rules-count" route identifier to the
withAuthwrapper follows the established pattern across the PR.apps/web/app/api/sso/signin/route.ts (3)
18-18: LGTM! Route identifier added for better logging context.The addition of the "sso/signin" route identifier to the
withErrorwrapper enables better API call logging.
25-25: LGTM! Migrated to request-scoped logging.Successfully migrated from module-scoped logger to
request.loggerfor better request context.
39-42: LGTM! Migrated to request-scoped logging.Error logging now uses
request.loggerfor consistent request-scoped logging throughout the handler.apps/web/app/api/user/categorize/senders/uncategorized/route.ts (1)
10-25: LGTM! Route identifier added for better logging context.The addition of the "user/categorize/senders/uncategorized" route identifier to the
withEmailAccountwrapper follows the established pattern across the PR.apps/web/app/api/unsubscribe/route.ts (5)
6-8: LGTM! Route identifier added and delegating to shared unsubscribe function.The GET handler now uses scoped
withError("unsubscribe", ...)and delegates to the sharedunsubscribefunction.
10-12: Verify: Inconsistent withError usage between GET and POST.The GET handler uses
withError("unsubscribe", ...)with a route scope (line 6), while the POST handler useswithError(...)without a scope (line 10). Both injectRequestWithLogger, so the cast on line 11 is safe but highlights the inconsistency.Should the POST handler also use
withError("unsubscribe", ...)for consistency with the GET handler?
63-66: LGTM! Migrated to request-scoped logging.Error logging now uses
request.loggerfor consistent request-scoped logging.
78-83: LGTM! Migrated to request-scoped logging.Error logging for token deletion now uses
request.logger.
85-87: LGTM! Migrated to request-scoped logging.Success logging now uses
request.loggerfor consistent request-scoped logging throughout the handler.apps/web/app/api/google/watch/all/route.ts (1)
131-131: LGTM! Route identifier added for better logging.The GET handler now includes the route identifier for request-scoped logging.
apps/web/app/api/user/stats/senders/route.ts (1)
82-82: LGTM! Route identifier properly added.The change adds request-scoped logging context for this endpoint.
apps/web/app/api/user/email-accounts/route.ts (1)
53-53: LGTM! Route identifier properly added.The authentication wrapper now includes the route identifier for improved observability.
apps/web/app/api/user/calendars/route.ts (1)
7-7: LGTM! Route identifier properly added.The change enhances logging context for this API route.
apps/web/app/api/user/rules/[id]/example/route.ts (1)
36-49: LGTM! Route identifier properly added.The email provider wrapper now includes the route identifier for better API call tracking.
apps/web/app/api/user/rules/prompt/route.ts (1)
14-14: LGTM! Route identifier properly added.The change adds proper logging context for this endpoint.
apps/web/app/api/user/group/[groupId]/items/route.ts (1)
26-38: LGTM! Route identifier properly added.The change properly adds logging context while preserving the route params handling.
apps/web/app/api/user/labels/route.ts (1)
13-13: LGTM! Route identifier properly added.The change enhances observability for this labels endpoint.
apps/web/app/api/user/rules/[id]/route.ts (1)
50-62: LGTM: Route identifier successfully added.The GET handler now registers the route identifier
"user/rules/detail"with the middleware wrapper, aligning with the PR's objective to improve API call logging. The inner handler logic remains unchanged and correct.apps/web/app/api/user/stats/newsletters/route.ts (1)
247-273: LGTM: Route identifier successfully added.The GET handler now registers the route identifier
"user/stats/newsletters"with the middleware wrapper, consistent with the PR's objective.apps/web/app/api/google/watch/route.ts (1)
9-9: LGTM: Route identifier and request-scoped logging successfully implemented.The GET handler has been updated to:
- Register the route identifier
"google/watch"with the middleware wrapper- Migrate from module-scoped logging to request-scoped logging using
request.loggerThese changes fully align with the PR's objectives for better API call logging.
Also applies to: 43-56
apps/web/app/api/user/stats/recipients/route.ts (1)
50-67: LGTM: Route identifier successfully added.The GET handler now registers the route identifier
"user/stats/recipients"with the middleware wrapper, consistent with the PR's objective to improve API call logging. The inner handler logic remains unchanged and correct.
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
2 participants
Summary by CodeRabbit
Note: This release consists primarily of internal infrastructure improvements with no user-facing changes.