packages/features/insights/server/trpc-router.ts (2)

322-324: Question the new status param on createInsightsBookingService.

Only the new “completed bookings” endpoints use this, and the status is later implemented via an extra column filter (time-based), not an actual booking status. If we switch endpoints to request “completed” directly from the service (see below), this parameter can be dropped to keep the helper simple and avoid param creep.

Apply this minimal simplification if you adopt the endpoint fix below:

-function createInsightsBookingService(
-  ctx: { user: { id: number; organizationId: number | null } },
-  input: z.infer<typeof bookingRepositoryBaseInputSchema>,
-  dateTarget: "createdAt" | "startTime" = "createdAt",
-  status: "completed" | "all" = "all"
-) {
+function createInsightsBookingService(
+  ctx: { user: { id: number; organizationId: number | null } },
+  input: z.infer<typeof bookingRepositoryBaseInputSchema>,
+  dateTarget: "createdAt" | "startTime" = "createdAt"
+) {

---

354-354: Use columnFilters as-is (after removing the “completed” time hack).

Once the time-based hack is removed, pass through columnFilters as provided by input to avoid unexpected server-side mutations.

-      ...(updatedColumnFilters && { columnFilters: updatedColumnFilters }),
+      ...(updatedColumnFilters && { columnFilters: updatedColumnFilters }),

Note: keep the local name or inline columnFilters if you revert the earlier block entirely.

packages/features/insights/components/booking/index.ts (1)

14-15: Exports Verified and Named Exports Match

Both components exist in packages/features/insights/components/booking and correctly export the expected tables:

• packages/features/insights/components/booking/MostCompletedBookings.tsx
  • Exports MostCompletedTeamMembersTable
• packages/features/insights/components/booking/LeastCompletedBookings.tsx
  • Exports LeastCompletedTeamMembersTable

You can safely import these in the insights view without breaking existing code.

Optional: If these tables fetch or render large datasets, consider lazy-loading them in the insights view to reduce the initial bundle size.

apps/web/modules/insights/insights-view.tsx (1)

93-96: Make layout consistent with other 2-up grids (span 2 cols at md).
In earlier sections, two-wide items span two columns on md (4-col grid) for better readability. These two tables currently render at 1/4 width each on md. Consider matching the pattern used for BookingsByHour/AverageEventDuration.

-        <div className="grid grid-cols-1 gap-4 sm:grid-cols-2 md:grid-cols-4">
-          <MostCompletedTeamMembersTable />
-          <LeastCompletedTeamMembersTable />
-        </div>
+        <div className="grid grid-cols-1 gap-4 sm:grid-cols-2 md:grid-cols-4">
+          <div className="sm:col-span-2">
+            <MostCompletedTeamMembersTable />
+          </div>
+          <div className="sm:col-span-2">
+            <LeastCompletedTeamMembersTable />
+          </div>
+        </div>

packages/features/insights/components/booking/LeastCompletedBookings.tsx (2)

28-34: Consider a lightweight error/empty state instead of silent null.
Returning null on error/empty makes the UI “blink out.” If there’s a shared or , use it for user feedback; otherwise, a small inline message suffices.

---

15-24: Centralize TRPC query options and maintain existing batching behavior
The inline TRPC options (staleTime, refetchOnWindowFocus, and trpc.context.skipBatch) are duplicated across nearly all insights booking tables and charts. Extract these into a shared constant to ensure consistency and simplify future tweaks:

• Create a new file for shared options, for example:

// packages/features/insights/constants.ts
export const INSIGHTS_QUERY_OPTIONS = {
  staleTime: 180_000,              // 3 minutes
  refetchOnWindowFocus: false,
  trpc: { context: { skipBatch: true } },
} as const;

• Update each component (e.g. LeastCompletedBookings.tsx):

-import { trpc } from '...';
+import { trpc } from '...';
+import { INSIGHTS_QUERY_OPTIONS } from 'packages/features/insights/constants';

   // ...
-  const { data, isSuccess, isPending } =
-    trpc.viewer.insights.membersWithLeastCompletedBookings.useQuery(
-      insightsBookingParams,
-      {
-        staleTime: 180000,
-        refetchOnWindowFocus: false,
-        trpc: { context: { skipBatch: true } },
-      }
-    );
+  const { data, isSuccess, isPending } =
+    trpc.viewer.insights.membersWithLeastCompletedBookings.useQuery(
+      insightsBookingParams,
+      INSIGHTS_QUERY_OPTIONS
+    );

Since skipBatch: true is already applied uniformly across all insights queries, this refactor preserves existing behavior. If you later determine that batching is safe, you can remove or adjust it centrally.

packages/features/insights/components/booking/MostCompletedBookings.tsx (2)

28-34: Optional: non-null fallback for errors/empty data.
To avoid silent disappearance, consider rendering a small Empty/Error component if available.

---

15-24: DRY-Up tRPC Query Options and Reevaluate skipBatch

Centralize the common query configuration into a shared constant and confirm whether you still need to disable batching for these insights endpoints.

• Extract the inline options (staleTime, refetchOnWindowFocus, trpc.context.skipBatch) into a single INSIGHTS_QUERY_OPTS constant.
• Apply the same extraction in both MostCompletedBookings.tsx and LeastCompletedBookings.tsx to avoid divergence.
• Since both server handlers invoke
  createInsightsBookingService(ctx, input, "startTime", "completed")
  with no special batching constraints, verify if you can safely remove skipBatch to leverage tRPC’s default request batching.

+const INSIGHTS_QUERY_OPTS = {
+  staleTime: 180_000,
+  refetchOnWindowFocus: false,
+  trpc: { context: { skipBatch: true } }, // ← consider removing if batching works
+} as const;

-const { data, isSuccess, isPending } = trpc.viewer.insights.membersWithMostCompletedBookings.useQuery(
-  insightsBookingParams,
-  {
-    staleTime: 180000,
-    refetchOnWindowFocus: false,
-    trpc: { context: { skipBatch: true } },
-  }
-);
+const { data, isSuccess, isPending } =
+  trpc.viewer.insights.membersWithMostCompletedBookings.useQuery(
+    insightsBookingParams,
+    INSIGHTS_QUERY_OPTS
+  );

• Repeat this change in packages/features/insights/components/booking/LeastCompletedBookings.tsx.
• After extraction, test without skipBatch and confirm via performance metrics or error logs that batching introduces no regressions.

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

Learnt from: Udit-takkar
PR: calcom/cal.com#22995
File: packages/trpc/server/routers/viewer/aiVoiceAgent/_router.ts:117-126
Timestamp: 2025-08-17T22:00:16.329Z
Learning: In calcom/cal.com PR #22995, packages/trpc/server/routers/viewer/aiVoiceAgent/_router.ts, the enabled input parameter in the update endpoint is intentionally not forwarded to aiService.updateAgentConfiguration() as the enabled/disabled agent functionality is not required at the moment (per maintainer Udit-takkar). Future reviews should not flag this as missing functionality unless requirements change.

Learnt from: eunjae-lee
PR: calcom/cal.com#22106
File: packages/features/insights/components/RoutingFunnel.tsx:15-17
Timestamp: 2025-07-15T12:58:40.539Z
Learning: In the insights routing funnel component (packages/features/insights/components/RoutingFunnel.tsx), the useColumnFilters exclusions are intentionally different from the general useInsightsParameters exclusions. RoutingFunnel specifically excludes only ["createdAt"] while useInsightsParameters excludes ["bookingUserId", "formId", "createdAt", "eventTypeId"]. This difference is by design.

packages/lib/server/service/InsightsBookingBaseService.ts (1)

804-806: Accepted type support added — resolves prior review ask.

The union now includes "accepted" and the signature default remains "all". This addresses the earlier feedback about handling the accepted type.

packages/lib/server/service/InsightsBookingBaseService.ts (3)

63-91: Strengthen schema typing for status to prevent invalid values slipping through.

status is declared as z.string() but represents BookingStatus. Use Prisma’s enum for compile-time safety and better validation.

-    status: z.string(), // BookingStatus enum
+    status: z.nativeEnum(Prisma.BookingStatus),

Optional: if there’s a well-defined set for timeStatus (e.g., "completed" | "rescheduled" | "cancelled" | "uncompleted"), consider a z.enum([...]) for it as well to catch typos early.

---

16-31: Avatar fallback may produce "/null/avatar.png" when username is null.

Guard username to avoid broken URLs until the AVATAR_FALLBACK migration lands.

-      avatarUrl: user.avatarUrl || `/${user.username}/avatar.png`,
+      avatarUrl: user.avatarUrl || (user.username ? `/${user.username}/avatar.png` : "/avatar.png"),

If there’s a shared avatar fallback constant/util elsewhere, prefer reusing it here.

---

818-832: Potential index needs for new query shape.

The accepted/completed path will filter on userId + status/timeStatus + date target. To keep this snappy on large datasets, ensure DB has supporting indexes on the view’s base tables:

• Composite index on BookingTimeStatusDenormalized(userId, status, timeStatus, startTime)
• For hour-of-day stats: index on (status, startTime)

If the view is materialized/denormalized by a job, ensure those indexes exist on the underlying table/view as applicable.

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

apps/web/modules/insights/insights-view.tsx (2)

89-90: Clarify date basis: global UI filter = createdAt, completed charts = startTime.

To avoid user confusion, consider a subtle hint on the completed charts (e.g., “Based on event start time”) or updating the page’s date filter label/tooltip to indicate createdAt is used for scheduled charts while completed charts use startTime. This aligns with the accepted-booking approach (endDate <= now) and the learning to avoid SQL-level endTime constraints.

Suggested manual check:

• Create a booking with createdAt in August but startTime in September.
• Set the page date range to August only.
• Expected: “Most/Least Bookings Scheduled” respect createdAt; “Completed” charts (none yet) use startTime and should not include September events until the range covers September and the booking has ended.

---

35-43: Prefer named export over default (module, not a page).

This module isn’t a top-level Next.js page/layout, so named exports are encouraged for tree-shaking and refactors.

Apply when low-risk to update import sites:

-export default function InsightsPage({ timeZone }: { timeZone: string }) {
+export function InsightsPage({ timeZone }: { timeZone: string }) {

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

Learnt from: bandhan-majumder
PR: calcom/cal.com#23192
File: packages/lib/server/service/InsightsBookingBaseService.ts:814-816
Timestamp: 2025-08-22T16:38:00.182Z
Learning: In the InsightsBookingBaseService (packages/lib/server/service/InsightsBookingBaseService.ts), when filtering for "accepted" bookings in getMembersStatsWithCount(), using `endTime <= now()` in the SQL condition should be avoided as it conflicts with existing date filtering logic. The components already handle completion filtering by setting `endDate: currentTime` in their query parameters, making additional SQL-level endTime filtering unnecessary and potentially problematic.

apps/web/public/static/locales/ru/common.json (1)

2169-2176: Add missing booking translation keys to Russian locale

The locale comparison shows that the following keys used by the new Insights UI are absent in apps/web/public/static/locales/ru/common.json:

• most_bookings_scheduled
• least_bookings_scheduled
• most_bookings_completed
• least_bookings_completed

Without these, users will see fallbacks or raw keys in the UI. Please insert them near the existing Insights strings (e.g., after "least_booked_members"):

--- a/apps/web/public/static/locales/ru/common.json
+++ b/apps/web/public/static/locales/ru/common.json
@@ ... "least_booked_members": "Наименее востребованные",
+  "most_bookings_scheduled": "Наибольшее количество запланированных бронирований",
+  "least_bookings_scheduled": "Наименьшее количество запланированных бронирований",
+  "most_bookings_completed": "Наибольшее количество завершённых бронирований",
+  "least_bookings_completed": "Наименьшее количество завершённых бронирований",

apps/web/public/static/locales/no/common.json (1)

3421-3422: Add missing Norwegian translations for new insights keys

The following four keys introduced in the PR are missing from the Norwegian locale, causing a fallback to English in the UI. Please insert them above the ADD_NEW_STRINGS_ABOVE_THIS_LINE_TO_PREVENT_MERGE_CONFLICTS guard in apps/web/public/static/locales/no/common.json:

   "usage_based_expiration_description_plural": "Denne lenken kan brukes for {{count}} bestillinger",
+  "most_bookings_scheduled": "Flest planlagte bookinger",
+  "least_bookings_scheduled": "Færrest planlagte bookinger",
+  "most_bookings_completed": "Flest fullførte bookinger",
+  "least_bookings_completed": "Færrest fullførte bookinger",
   "ADD_NEW_STRINGS_ABOVE_THIS_LINE_TO_PREVENT_MERGE_CONFLICTS": "↑↑↑↑↑↑↑↑↑↑↑↑↑ Legg til dine nye strenger over her ↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑"

• File: apps/web/public/static/locales/no/common.json
• Insert above the ADD_NEW_STRINGS… line at the end of the file.

This ensures the UI displays proper Norwegian translations rather than defaulting to English.

apps/web/public/static/locales/bg/common.json (1)

2171-2176: Add the four new Insights titles to keep BG locale in sync with EN and the new charts

The PR introduces/renames charts to “Most/Least Bookings Scheduled” and adds “Most/Least Bookings Completed”, with EN keys present. BG locale is missing these keys, so users on BG will see EN fallbacks or raw keys. Add the strings near the existing insights keys.

Apply this diff (place above the “ADD_NEW_STRINGS…” sentinel and alongside the existing insights keys):

   "most_booked_members": "Най-резервирани",
   "least_booked_members": "Най-малко резервирани",
+  "most_bookings_scheduled": "Най-много планирани резервации",
+  "least_bookings_scheduled": "Най-малко планирани резервации",
+  "most_bookings_completed": "Най-много завършени резервации",
+  "least_bookings_completed": "Най-малко завършени резервации",
   "events_created": "Създадени събития",
   "events_completed": "Завършени събития",

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

Learnt from: bandhan-majumder
PR: calcom/cal.com#23192
File: packages/lib/server/service/InsightsBookingBaseService.ts:814-816
Timestamp: 2025-08-22T16:38:00.182Z
Learning: In the InsightsBookingBaseService (packages/lib/server/service/InsightsBookingBaseService.ts), when filtering for "accepted" bookings in getMembersStatsWithCount(), using `endTime <= now()` in the SQL condition should be avoided as it conflicts with existing date filtering logic. The components already handle completion filtering by setting `endDate: currentTime` in their query parameters, making additional SQL-level endTime filtering unnecessary and potentially problematic.