apps/web/components/booking/bookingActions.report.test.ts (2)

9-121: Well-structured mock factory with good override capability.

The createMockContext function provides comprehensive mock data and allows for flexible customization through the overrides parameter. The Date calculations are straightforward and appropriate for test scenarios.

Consider extracting the time calculations to constants for better readability:

function createMockContext(overrides: Partial<BookingActionContext> = {}): BookingActionContext {
  const now = new Date();
+  const ONE_DAY_MS = 24 * 60 * 60 * 1000;
+  const ONE_HOUR_MS = 60 * 60 * 1000;
-  const startTime = new Date(now.getTime() + 24 * 60 * 60 * 1000); // Tomorrow
-  const endTime = new Date(startTime.getTime() + 60 * 60 * 1000); // 1 hour later
+  const startTime = new Date(now.getTime() + ONE_DAY_MS); // Tomorrow
+  const endTime = new Date(startTime.getTime() + ONE_HOUR_MS); // 1 hour later

---

157-187: Good coverage for timing scenarios.

The tests properly verify that report actions are available for both past and upcoming bookings, ensuring the feature works across different time contexts.

For consistency with the earlier suggestion, consider extracting the time calculation constants:

    it("should return report action for past bookings", () => {
+      const ONE_DAY_MS = 24 * 60 * 60 * 1000;
+      const ONE_HOUR_MS = 60 * 60 * 1000;
-      const pastDate = new Date(Date.now() - 24 * 60 * 60 * 1000); // Yesterday
+      const pastDate = new Date(Date.now() - ONE_DAY_MS); // Yesterday
      const context = createMockContext({
        booking: {
          startTime: pastDate.toISOString(),
-          endTime: new Date(pastDate.getTime() + 60 * 60 * 1000).toISOString(),
+          endTime: new Date(pastDate.getTime() + ONE_HOUR_MS).toISOString(),
        } as any,

apps/web/public/static/locales/en/common.json (2)

3389-3404: Prefer namespacing & avoid overly-generic keys

Keys such as "report", "reason_required" or "reported" are very broad and risk clashing with future, unrelated strings.
Consider prefixing all new entries with a shared context, e.g. report_booking_*, to keep the dictionary tidy and self-describing:

-  "report": "Report",
-  "reason_required": "Reason is required",
-  "reported": "Reported",
+  "report_booking_action": "Report",
+  "report_booking_reason_required": "Reason is required",
+  "report_booking_status_reported": "Reported",

This also makes dead-key searches & i18n extraction easier.
(Other keys in this block already follow the pattern, so aligning all of them keeps things consistent.)

---

3399-3401: Slight wording improvement

"attendee_not_notified_report" reads awkwardly.
Suggestion:

-  "attendee_not_notified_report": "Attendee will not be notified that this booking was reported"
+  "attendee_not_notified_report": "Attendee will not be notified that this booking has been reported"

Present-perfect tense is more natural here.

apps/web/components/dialog/ReportBookingDialog.tsx (2)

34-42: Remove unused parameter

The bookingTitle parameter is renamed to _bookingTitle but never used in the component.

Either remove the parameter from the interface and props, or use it if it's intended for future use:

 export function ReportBookingDialog({
   isOpen,
   onClose,
   bookingId,
-  bookingTitle: _bookingTitle,
   isUpcoming,
   isCancelled = false,
   onSuccess,
 }: ReportBookingDialogProps) {

---

79-84: Consider optimizing form reset behavior

The form is reset both when closing the dialog and after successful submission. Consider resetting only on successful submission to preserve user input if they accidentally close the dialog.

 const handleClose = () => {
   if (!isSubmitting) {
     onClose();
-    form.reset();
   }
 };

packages/trpc/server/routers/viewer/bookings/reportBooking.handler.ts (2)

52-56: Optimize team admin/owner authorization checks

The current implementation awaits each check sequentially. Consider parallelizing these checks for better performance.

-  const isTeamAdminOrOwner =
-    booking.eventType?.teamId &&
-    ((await isTeamAdmin(user.id, booking.eventType.teamId)) ||
-      (await isTeamOwner(user.id, booking.eventType.teamId)));
+  let isTeamAdminOrOwner = false;
+  if (booking.eventType?.teamId) {
+    const [isAdmin, isOwner] = await Promise.all([
+      isTeamAdmin(user.id, booking.eventType.teamId),
+      isTeamOwner(user.id, booking.eventType.teamId)
+    ]);
+    isTeamAdminOrOwner = isAdmin || isOwner;
+  }

---

22-44: Consider optimizing the duplicate report check

Instead of fetching all reports and checking length, consider using a count query or exists check for better performance.

Update the booking query to only check if a report exists:

       reports: {
+        take: 1,
         where: {
           reportedById: user.id,
         },
       },

This will limit the query to fetch at most one report, which is sufficient for the existence check.

packages/prisma/migrations/20250723214119_add_booking_report/migration.sql (1)

1-2: Consider consistent enum naming convention

The enum value 'dont_know_person' uses snake_case while 'SPAM' and 'OTHER' use UPPER_CASE. Consider using consistent naming.

-CREATE TYPE "ReportReason" AS ENUM ('SPAM', 'dont_know_person', 'OTHER');
+CREATE TYPE "ReportReason" AS ENUM ('SPAM', 'DONT_KNOW_PERSON', 'OTHER');

Note: This would require updating the Prisma schema mapping as well.

apps/web/components/booking/BookingListItem.tsx (1)

403-419: Improve readability and consider edge cases.

The logic correctly adds a report action for non-cancelled bookings, but could be improved:

1. The conditional logic could be more readable
2. Consider extracting the report action creation into a helper function for reusability

+const createReportAction = (hasBeenReported: boolean, onReport: () => void): ActionType => {
+  return hasBeenReported
+    ? {
+        id: "report",
+        label: t("already_reported"),
+        icon: "flag",
+        disabled: true,
+      }
+    : {
+        id: "report",
+        label: t("report"),
+        icon: "flag",
+        disabled: false,
+        onClick: onReport,
+      };
+};

 if (!isCancelled) {
-  const reportAction: ActionType = hasBeenReported
-    ? {
-        id: "report",
-        label: t("already_reported"),
-        icon: "flag",
-        disabled: true,
-      }
-    : {
-        id: "report",
-        label: t("report"),
-        icon: "flag",
-        disabled: false,
-        onClick: () => setIsReportDialogOpen(true),
-      };
+  const reportAction = createReportAction(hasBeenReported, () => setIsReportDialogOpen(true));
   afterEventActions.push(reportAction);
 }

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

packages/trpc/server/routers/viewer/bookings/reportBooking.handler.ts (1)

76-97: Improved error handling addresses previous feedback.

The cancellation error handling has been significantly improved from the previous review. The implementation now:

• Captures cancellation errors properly
• Provides clear error messages to users
• Returns error details in the response

This addresses the previous concern about silent cancellation failures.

packages/trpc/server/routers/viewer/bookings/reportBooking.handler.ts (2)

22-45: Consider optimizing the database query structure.

While the query is functionally correct, the nested include structure could be optimized for better performance and maintainability.

Consider flattening the query structure and using more specific selections:

  const booking = await prisma.booking.findUnique({
    where: {
      id: bookingId,
    },
    include: {
      attendees: {
        select: {
          email: true,
        },
      },
      eventType: {
        select: {
+         teamId: true,
-         team: {
-           select: {
-             id: true,
-             name: true,
-             parentId: true,
-           },
-         },
        },
      },
      reports: {
        where: {
          reportedById: user.id,
        },
+       select: {
+         id: true,
+       },
      },
    },
  });

This reduces the data transferred and improves query performance by only selecting necessary fields.

---

62-64: Good duplicate prevention, but consider the user experience.

The logic correctly prevents duplicate reports, but the error message could be more user-friendly.

Consider a more informative error message:

  if (booking.reports.length > 0) {
-   throw new TRPCError({ code: "BAD_REQUEST", message: "You have already reported this booking" });
+   throw new TRPCError({ 
+     code: "BAD_REQUEST", 
+     message: "You have already reported this booking. Multiple reports are not allowed." 
+   });
  }

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

apps/web/components/booking/BookingListItem.tsx (1)

855-867: Localize “Unknown” and guard reason key mapping.

Hardcoded “Unknown” violates the i18n guideline for TSX. Also, ensure the reason key exists before lowercasing.

-          hasAnyReport && (
-            <Badge variant="red" className="ltr:mr-2 rtl:ml-2">
-              {t("reported")}:{" "}
-              {booking.reports?.[0]?.reason ? t(booking.reports?.[0]?.reason?.toLowerCase()) : "Unknown"}
-            </Badge>
-          )
+          hasAnyReport && (
+            <Badge variant="red" className="ltr:mr-2 rtl:ml-2">
+              {t("reported")}:{" "}
+              {typeof booking.reports?.[0]?.reason === "string"
+                ? t(booking.reports[0].reason.toLowerCase())
+                : t("unknown")}
+            </Badge>
+          )

Ensure the unknown key exists in locales.

apps/web/components/dialog/ReportBookingDialog.tsx (2)

38-41: Remove unused prop to reduce API surface (or use it in the UI).

bookingTitle is accepted but unused (bookingTitle: _bookingTitle). Either display it (e.g., in the dialog header/subtitle) or drop it from props.

-  bookingTitle: string;
+  // Remove if not used
+  // bookingTitle: string;

If you keep it, consider showing it under the title for context: “Report booking: {bookingTitle}”.

---

104-107: Use explicit required rule for react-hook-form for clarity.

Passing required: t("reason_required") is valid. Using the object form improves readability and type clarity.

-              rules={{ required: t("reason_required") }}
+              rules={{ required: { value: true, message: t("reason_required") } }}

apps/web/components/booking/bookingActions.report.test.ts (3)

125-136: Add test coverage for “already reported” (disabled) state.

The spec requires preventing re-reporting. Add a case where the booking has existing reports and assert the action is disabled or the label reflects “already_reported”.

Example (if getReportActions is enhanced to respect reported state via context):

   describe("getReportActions", () => {
+    it("should disable report action if already reported", () => {
+      const context = createMockContext({
+        booking: { reports: [{ id: 1 }] } as any,
+      });
+      const actions = getReportActions(context);
+      expect(actions).toHaveLength(1);
+      expect(actions[0].id).toBe("report");
+      expect(actions[0].disabled).toBe(true);
+    });

Note: Today getReportActions ignores reported state; either wire it up or move tests to where the logic lives (BookingListItem).

---

139-155: Broaden scenarios: cancelled and unconfirmed-specific expectations.

You test various statuses generically. Add explicit cases for:

• Cancelled bookings (ensure action is present and later rendered inline in UI).
• Unconfirmed bookings (ensure presence too).

This documents the intended behavior across tabs and prevents regressions.

---

9-13: Stabilize test time references to avoid flakiness.

Tests compute “tomorrow”/“yesterday” based on Date.now(). When crossing midnight on CI, assertions can flicker. Freeze time with vi.setSystemTime(new Date("2025-01-01T12:00:00Z")) in a beforeAll and restore in afterAll.

Also applies to: 14-41

apps/web/components/booking/BookingListItem.tsx (5)

86-90: Recurring-series awareness: reporting check only inspects the single booking.

checkIfBookingReported uses booking.reports.length only. If a report was filed on another occurrence and the intended UX is to show “Reported” for the whole series, this won’t reflect that unless the server populates series-level reports onto each item.

• If the server augments each occurrence with a series flag (e.g., booking.hasBeenReportedByUser or booking.seriesReported), use that instead.
• Otherwise, consider extending the query to return “seriesHasReports” when recurringEventId != null, or pass a prop computed at the list level.

I can generate a small PR to thread a seriesHasReports boolean through the handler and UI; let me know.

---

409-429: Deduplicate action construction by centralizing in getReportActions(context).

You re-implement report action logic locally. We already expose getReportActions(context) in bookingActions.ts. Move the “already reported” disabling and labels into that function and reuse it here to keep behavior consistent in all consumers.

Proposed shape for getReportActions (outside this file):

export function getReportActions(context: BookingActionContext): ActionType[] {
  const { t, booking } = context;
  const hasBeenReported = !!booking.reports?.length;
  return [
    hasBeenReported
      ? { id: "report", label: t("already_reported"), icon: "flag", disabled: true }
      : { id: "report", label: t("report"), icon: "flag", disabled: false },
  ];
}

Then, here you can map to either inline or menu presentation:

-const individualReportAction: ActionType | null = shouldShowIndividualReportButton
-  ? createReportAction(hasBeenReported, () => setIsReportDialogOpen(true))
-  : null;
+const [baseReportAction] = getReportActions(actionContext);
+const individualReportAction: ActionType | null =
+  shouldShowIndividualReportButton
+    ? { ...baseReportAction, onClick: () => setIsReportDialogOpen(true) }
+    : null;

-const reportActionForMenu: ActionType | null = shouldShowReportInThreeDotsMenu
-  ? createReportAction(hasBeenReported, () => setIsReportDialogOpen(true))
-  : null;
+const reportActionForMenu: ActionType | null =
+  shouldShowReportInThreeDotsMenu
+    ? { ...baseReportAction, onClick: () => setIsReportDialogOpen(true) }
+    : null;

---

744-759: Minor accessibility: menu item should be a button, not a link, when no href.

DropdownItem supports type="button" (you set it) but it renders interactive content. Ensure it doesn’t render an anchor without href (component-dependent). If it does, prefer a button to avoid href="#" anti-pattern.

---

765-779: Tooltip is localized, good. Consider aria-label for icon-only action.

The inline report button is icon-only. You pass tooltip, but for screen readers include aria-label={individualReportAction.label} to improve accessibility.

-                <Button
+                <Button
                   type="button"
                   variant="icon"
                   color="secondary"
                   StartIcon={individualReportAction.icon}
                   onClick={individualReportAction.onClick}
                   disabled={individualReportAction.disabled}
                   data-testid={individualReportAction.id}
                   className="h-8 w-8"
-                  tooltip={individualReportAction.label}
+                  tooltip={individualReportAction.label}
+                  aria-label={individualReportAction.label}
                 />

---

798-811: Avoid invalidating the entire tRPC cache; scope invalidation to bookings.

utils.invalidate() nukes all caches and can cause unnecessary network traffic/UI jank. Invalidate only the relevant queries.

         onSuccess={async () => {
           // Invalidate all booking queries to ensure UI reflects the changes
           await utils.viewer.bookings.invalidate();
-          // Also invalidate any cached booking data
-          await utils.invalidate();
+          // If needed, also invalidate specific detail queries, e.g.:
+          // await utils.viewer.bookings.get.invalidate();
         }}

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: eunjae-lee
PR: calcom/cal.com#22106
File: packages/features/insights/components/FailedBookingsByField.tsx:65-71
Timestamp: 2025-07-15T12:59:34.389Z
Learning: In the FailedBookingsByField component (packages/features/insights/components/FailedBookingsByField.tsx), although routingFormId is typed as optional in useInsightsParameters, the system automatically enforces a routing form filter, so routingFormId is always present in practice. This means the data always contains only one entry, making the single-entry destructuring approach safe.

Learnt from: alishaz-polymath
PR: calcom/cal.com#23247
File: packages/features/webhooks/lib/factory/WebhookPayloadFactory.ts:274-282
Timestamp: 2025-08-21T12:28:42.000Z
Learning: In BookingPaymentInitiatedDTO and other webhook DTOs in packages/features/webhooks/lib/dto/types.ts, the booking field is a restricted structure containing only specific fields (id, eventTypeId, userId) rather than the full database booking object, so there are no security or PII leakage concerns when passing the booking object to buildEventPayload.

Learnt from: alishaz-polymath
PR: calcom/cal.com#23247
File: packages/features/webhooks/lib/factory/WebhookPayloadFactory.ts:274-282
Timestamp: 2025-08-21T12:28:42.000Z
Learning: In webhook DTOs in packages/features/webhooks/lib/dto/types.ts, the booking fields are restricted structures containing only specific fields (id, eventTypeId, userId, and sometimes additional fields like startTime or smsReminderNumber) rather than full database booking objects, so there are no security or PII leakage concerns when using these booking objects in webhook payloads.

Learnt from: supalarry
PR: calcom/cal.com#23217
File: apps/api/v2/src/ee/event-types/event-types_2024_06_14/services/output-event-types.service.ts:93-94
Timestamp: 2025-08-21T13:44:06.784Z
Learning: In apps/api/v2/src/ee/event-types/event-types_2024_06_14/event-types.repository.ts, repository functions that use explicit Prisma select clauses (like getEventTypeWithSeats) are used for specific purposes and don't need to include all EventType fields like bookingRequiresAuthentication. These methods don't feed into the general OutputEventTypesService_2024_06_14 flow.

apps/web/components/booking/BookingListItem.tsx (1)

430-434: Verify UX rule: placement of Report action across tabs/states.

• You show inline button for recurring tab, pending, and cancelled; menu otherwise.
• PR objective: dropdown for upcoming/past; inline next to “Video Options” for cancelled.

Pending/unconfirmed inline wasn’t in the initial spec but was requested in comments. Confirm this is the final desired UX and that it doesn’t crowd the header in dense lists.

apps/web/components/booking/BookingListItem.tsx (1)

413-442: Nice extraction of a reusable report action factory.

This addresses the earlier DRY comment around duplicated “report” action construction for different contexts.

apps/web/components/booking/BookingListItem.tsx (3)

855-867: Localize the “Unknown” fallback in the Reported badge.

Direct string breaks i18n. Use t("unknown") (or add it if missing).

-              {t("reported")}:{" "}
-              {booking.reports?.[0]?.reason ? t(booking.reports?.[0]?.reason?.toLowerCase()) : "Unknown"}
+              {t("reported")}:{" "}
+              {booking.reports?.[0]?.reason
+                ? t(booking.reports?.[0]?.reason?.toLowerCase())
+                : t("unknown")}

---

765-779: Add an accessible name to the icon-only “Report” button.

Provide aria-label so screen readers can announce the action.

 <Button
   type="button"
   variant="icon"
   color="secondary"
   StartIcon={individualReportAction.icon}
   onClick={individualReportAction.onClick}
   disabled={individualReportAction.disabled}
   data-testid={individualReportAction.id}
   className="h-8 w-8"
-  tooltip={individualReportAction.label}
+  tooltip={individualReportAction.label}
+  aria-label={individualReportAction.label}
 />

---

798-812: Scope cache invalidation to bookings to avoid unnecessary refetches.

utils.invalidate() nukes all TRPC caches and can cause extra network/CPU churn. In most cases, utils.viewer.bookings.invalidate() is sufficient.

         onSuccess={async () => {
           // Invalidate all booking queries to ensure UI reflects the changes
           await utils.viewer.bookings.invalidate();
-          // Also invalidate any cached booking data
-          await utils.invalidate();
         }}

packages/prisma/schema.prisma (1)

758-777: Drop redundant non-unique index on bookingId; keep the unique one.

You already have bookingId marked @unique which creates a unique index. The additional @@index([bookingId]) is redundant overhead.

 model BookingReport {
   id           String       @id @default(uuid())
   booking      Booking      @relation(fields: [bookingId], references: [id], onDelete: Cascade)
-  bookingId    Int          @unique
+  bookingId    Int          @unique
   reportedBy   User         @relation(fields: [reportedById], references: [id], onDelete: Cascade)
   reportedById Int
   reason       ReportReason
   description  String?
   cancelled    Boolean      @default(false)
   createdAt    DateTime     @default(now())

-  @@index([bookingId])
   @@index([reportedById])
 }

Optional: if you expect sorting/filtering by recency, consider @@index([createdAt]).

packages/prisma/migrations/20250823231324_add_booking_report/migration.sql (1)

17-24: Remove redundant non-unique index on bookingId (unique already exists).

BookingReport_bookingId_key creates a unique index; BookingReport_bookingId_idx duplicates it and can be dropped.

 -- CreateIndex
-CREATE UNIQUE INDEX "BookingReport_bookingId_key" ON "BookingReport"("bookingId");
+CREATE UNIQUE INDEX "BookingReport_bookingId_key" ON "BookingReport"("bookingId");

 -- CreateIndex
-CREATE INDEX "BookingReport_bookingId_idx" ON "BookingReport"("bookingId");
+-- (removed redundant non-unique index on bookingId)

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: eunjae-lee
PR: calcom/cal.com#23166
File: packages/prisma/migrations/20250818151914_routing_form_response_denormalized_backfill2/migration.sql:65-66
Timestamp: 2025-08-19T09:47:49.478Z
Learning: The Booking table has a unique constraint and index on the uid column (defined as `uid String unique` in schema.prisma), so JOINs on Booking.uid have optimal performance and don't require additional indexing.

Learnt from: eunjae-lee
PR: calcom/cal.com#22106
File: packages/features/insights/components/FailedBookingsByField.tsx:65-71
Timestamp: 2025-07-15T12:59:34.389Z
Learning: In the FailedBookingsByField component (packages/features/insights/components/FailedBookingsByField.tsx), although routingFormId is typed as optional in useInsightsParameters, the system automatically enforces a routing form filter, so routingFormId is always present in practice. This means the data always contains only one entry, making the single-entry destructuring approach safe.

Learnt from: alishaz-polymath
PR: calcom/cal.com#23247
File: packages/features/webhooks/lib/factory/WebhookPayloadFactory.ts:274-282
Timestamp: 2025-08-21T12:28:42.000Z
Learning: In BookingPaymentInitiatedDTO and other webhook DTOs in packages/features/webhooks/lib/dto/types.ts, the booking field is a restricted structure containing only specific fields (id, eventTypeId, userId) rather than the full database booking object, so there are no security or PII leakage concerns when passing the booking object to buildEventPayload.

Learnt from: alishaz-polymath
PR: calcom/cal.com#23247
File: packages/features/webhooks/lib/factory/WebhookPayloadFactory.ts:274-282
Timestamp: 2025-08-21T12:28:42.000Z
Learning: In webhook DTOs in packages/features/webhooks/lib/dto/types.ts, the booking fields are restricted structures containing only specific fields (id, eventTypeId, userId, and sometimes additional fields like startTime or smsReminderNumber) rather than full database booking objects, so there are no security or PII leakage concerns when using these booking objects in webhook payloads.

Learnt from: supalarry
PR: calcom/cal.com#23217
File: apps/api/v2/src/ee/event-types/event-types_2024_06_14/services/output-event-types.service.ts:93-94
Timestamp: 2025-08-21T13:44:06.784Z
Learning: In apps/api/v2/src/ee/event-types/event-types_2024_06_14/event-types.repository.ts, repository functions that use explicit Prisma select clauses (like getEventTypeWithSeats) are used for specific purposes and don't need to include all EventType fields like bookingRequiresAuthentication. These methods don't feed into the general OutputEventTypesService_2024_06_14 flow.

apps/web/components/booking/BookingListItem.tsx (1)

86-90: Verify reports.reason is selected in bookings.get

I didn’t see any reports field being selected in the TRPC “bookings.get” handler (packages/trpc/server/routers/viewer/bookings/get.handler.ts), yet the list component expects booking.reports?.[0]?.reason. Please manually confirm that your database query includes exactly:

select: {
  reports: {
    select: { reason: true }
  },
  // …other needed fields
}

and that you’re not using an include: { reports: true } (which pulls back full report objects).
If it’s missing or currently included in full, update the handler’s query to use a minimal select on reports.reason so you only fetch the data the UI needs.

packages/prisma/schema.prisma (1)

845-846: Relation looks good. One-report-per-booking invariant enforced at the DB level.

The reports: BookingReport[] relation on Booking aligns with the UI/handler behavior, and the unique (bookingId) enforces the “only one report per booking” product decision.

apps/web/components/booking/BookingListItem.tsx (5)

409-412: Simplify: avoid useMemo here.

The check is O(1) and unlikely to cause re-renders on its own. Removing useMemo reduces noise.

Apply:

-const hasBeenReported = useMemo(() => {
-  return checkIfBookingReported(booking);
-}, [booking]);
+const hasBeenReported = Boolean(booking.reports?.length);

---

765-779: Add an accessible name to the icon-only button.

Relying on a tooltip may not set an aria-label. Use the action label for screen readers.

 <Button
   type="button"
   variant="icon"
   color="secondary"
   StartIcon={individualReportAction.icon}
   onClick={individualReportAction.onClick}
   disabled={individualReportAction.disabled}
   data-testid={individualReportAction.id}
   className="h-8 w-8"
-  tooltip={individualReportAction.label}
+  tooltip={individualReportAction.label}
+  aria-label={individualReportAction.label}
 />

---

798-811: Avoid double invalidation to reduce unnecessary refetches.

utils.viewer.bookings.invalidate() is sufficient; utils.invalidate() purges everything and can be costly.

         onSuccess={async () => {
           // Invalidate all booking queries to ensure UI reflects the changes
           await utils.viewer.bookings.invalidate();
-          // Also invalidate any cached booking data
-          await utils.invalidate();
         }}

---

855-867: i18n: remove hardcoded “Unknown” and avoid brittle toLowerCase mapping for reason.

• Hardcoded “Unknown” violates our i18n guideline; use t().
• Mapping reason via toLowerCase assumes enum string shapes. Use an explicit map for stability.

Apply within this block:

-        return (
-          hasAnyReport && (
-            <Badge variant="red" className="ltr:mr-2 rtl:ml-2">
-              {t("reported")}:{" "}
-              {booking.reports?.[0]?.reason ? t(booking.reports?.[0]?.reason?.toLowerCase()) : "Unknown"}
-            </Badge>
-          )
-        );
+        const reason = booking.reports?.[0]?.reason;
+        const reasonKeyMap: Record<string, string> = {
+          SPAM: "spam",
+          DONT_KNOW_THIS_PERSON: "dont_know_this_person",
+          OTHER: "other",
+        };
+        const reasonKey = reason ? reasonKeyMap[reason] : undefined;
+        return (
+          hasAnyReport && (
+            <Badge variant="red" className="ltr:mr-2 rtl:ml-2">
+              {t("reported")}: {reasonKey ? t(reasonKey) : t("unknown")}
+            </Badge>
+          )
+        );

Outside this range, ensure we have a translation key for “unknown” in common.json (or reuse an existing one). If you prefer strong typing, import ReportReason and type reasonKeyMap as Record<ReportReason, string>.

Would you like me to push a follow-up to add the “unknown” key if it’s missing in locales?

---

86-91: Clarify booking-vs-series reporting and tighten the Boolean check

After digging into the backend handler, each booking’s reports array is populated only with reports whose bookingId matches that booking’s own ID—there’s no series-level aggregation today. We should therefore update our comments and utility to reflect “this specific booking” rather than implying “any booking in the recurring series.” While this is non-blocking, it will prevent future confusion if series-wide reporting ever becomes a feature.

• File: apps/web/components/booking/BookingListItem.tsx
– Lines 86–91: update the utility’s comment and return statement
– Line 857: revise the inline usage comment that currently reads
“Check if this booking or any booking in the recurring series has been reported”

Suggested diff:

--- a/apps/web/components/booking/BookingListItem.tsx
+++ b/apps/web/components/booking/BookingListItem.tsx
@@ -86,9 +86,7 @@
 // Utility function to check if a booking has been reported
-const checkIfBookingReported = (booking: BookingItemProps): boolean => {
-  // Check if this booking has been reported by anyone
-  return booking.reports && booking.reports.length > 0;
-};
+// Utility: has this specific booking been reported?
+const checkIfBookingReported = (booking: BookingItemProps): boolean =>
+  Boolean(booking.reports?.length);

@@ -855,7 +853,7 @@
-       // Check if this booking or any booking in the recurring series has been reported
-        const hasAnyReport = checkIfBookingReported(booking);
+        // Check if this specific booking has been reported
+        const hasAnyReport = checkIfBookingReported(booking);

packages/lib/server/queries/teams/index.ts (1)

441-446: Remove unnecessary type assertions on organizationId

Use a simple null check to avoid the as number casts and keep the where clause cleaner.

Apply this diff:

-      ...((organizationId ?? null) !== null
-        ? {
-            OR: [{ teamId: organizationId as number }, { team: { parentId: organizationId as number } }],
-          }
-        : {}),
+      ...(organizationId != null
+        ? {
+            OR: [{ teamId: organizationId }, { team: { parentId: organizationId } }],
+          }
+        : {}),

packages/trpc/server/routers/viewer/bookings/reportBooking.handler.ts (4)

72-75: Drop redundant isTeamOwner() call

isTeamAdmin() already checks for role in ["ADMIN", "OWNER"]. The extra isTeamOwner() call doubles the queries with no benefit.

Apply this diff:

-    isTeamAdminOrOwner =
-      !!(await isTeamAdmin(user.id, booking.eventType.teamId)) ||
-      (await isTeamOwner(user.id, booking.eventType.teamId));
+    isTeamAdminOrOwner = !!(await isTeamAdmin(user.id, booking.eventType.teamId));

---

26-60: Avoid N+1 by selecting owner email with the booking

You fire a separate query to fetch the booking owner’s email. Select it in the initial booking query instead and remove the extra roundtrip.

Apply this diff:

     select: {
       id: true,
       userId: true,
+      user: { select: { email: true } },
       uid: true,
       startTime: true,
       status: true,
       recurringEventId: true,

-    let isBookingOwnerTeamMember = false;
-    if (booking.userId) {
-      const bookingOwner = await prisma.user.findUnique({
-        where: { id: booking.userId },
-        select: { email: true },
-      });
-      isBookingOwnerTeamMember = !!(bookingOwner && teamMemberEmailList.includes(bookingOwner.email));
-    }
+    const isBookingOwnerTeamMember =
+      !!booking.user?.email && teamMemberEmailList.includes(booking.user.email);

Also applies to: 118-124

---

139-145: Tighten query to existence only

You only need to know if any report exists for the series. Select just the id to minimize payload.

Apply this diff:

   const existingRecurringReport = await prisma.bookingReport.findFirst({
     where: {
       booking: {
         recurringEventId: booking.recurringEventId,
       },
     },
+    select: { id: true },
   });

---

203-205: Use the shared logger instead of console.error

Align with the codebase’s logging pattern and add context.

Apply this diff:

-      cancellationError = error;
-      console.error("Failed to cancel booking after reporting:", error);
+      cancellationError = error;
+      // import logger at top: import logger from "@calcom/lib/logger";
+      logger.error(
+        { bookingId: booking.id, uid: booking.uid, userId: user.id, error },
+        "Failed to cancel booking after reporting"
+      );

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: supalarry
PR: calcom/cal.com#23217
File: apps/api/v2/src/ee/event-types/event-types_2024_06_14/services/output-event-types.service.ts:93-94
Timestamp: 2025-08-21T13:44:06.784Z
Learning: In apps/api/v2/src/ee/event-types/event-types_2024_06_14/event-types.repository.ts, repository functions that use explicit Prisma select clauses (like getEventTypeWithSeats) are used for specific purposes and don't need to include all EventType fields like bookingRequiresAuthentication. These methods don't feed into the general OutputEventTypesService_2024_06_14 flow.

Learnt from: CR
PR: calcom/cal.com#0
File: .cursor/rules/review.mdc:0-0
Timestamp: 2025-07-28T11:50:23.946Z
Learning: Applies to **/*.ts : For Prisma queries, only select data you need; never use `include`, always use `select`

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.

Learnt from: eunjae-lee
PR: calcom/cal.com#22106
File: packages/features/insights/components/FailedBookingsByField.tsx:65-71
Timestamp: 2025-07-15T12:59:34.389Z
Learning: In the FailedBookingsByField component (packages/features/insights/components/FailedBookingsByField.tsx), although routingFormId is typed as optional in useInsightsParameters, the system automatically enforces a routing form filter, so routingFormId is always present in practice. This means the data always contains only one entry, making the single-entry destructuring approach safe.

Learnt from: alishaz-polymath
PR: calcom/cal.com#23247
File: packages/features/webhooks/lib/factory/WebhookPayloadFactory.ts:274-282
Timestamp: 2025-08-21T12:28:42.000Z
Learning: In BookingPaymentInitiatedDTO and other webhook DTOs in packages/features/webhooks/lib/dto/types.ts, the booking field is a restricted structure containing only specific fields (id, eventTypeId, userId) rather than the full database booking object, so there are no security or PII leakage concerns when passing the booking object to buildEventPayload.

Learnt from: alishaz-polymath
PR: calcom/cal.com#23247
File: packages/features/webhooks/lib/factory/WebhookPayloadFactory.ts:274-282
Timestamp: 2025-08-21T12:28:42.000Z
Learning: In webhook DTOs in packages/features/webhooks/lib/dto/types.ts, the booking fields are restricted structures containing only specific fields (id, eventTypeId, userId, and sometimes additional fields like startTime or smsReminderNumber) rather than full database booking objects, so there are no security or PII leakage concerns when using these booking objects in webhook payloads.

apps/web/components/booking/BookingListItem.tsx (6)

3-3: LGTM: useMemo import is appropriate.

Imported useMemo is used below for hasBeenReported; no concerns.

---

55-55: Good: ReportBookingDialog imported in the right layer.

Import location and usage align with our dialog composition pattern.

---

141-141: State wiring for report dialog looks good.

Simple and consistent with other dialog states in this component.

---

413-429: Nice DRY extraction for report actions.

This addresses earlier duplication and keeps the menu/inline actions in sync.

---

430-441: Visibility logic matches the product requirements; please re-verify pending/recurring UX.

• Inline button for pending and cancelled bookings aligns with “unconfirmed” and “cancelled” visibility.
• Menu item for standard upcoming/past bookings is covered via shouldShowReportInThreeDotsMenu.

Quick sanity checks to run in Storybook/E2E:

• Unconfirmed booking: inline “Report” icon is visible and clickable.
• Cancelled booking: inline “Report” icon is visible (as per designs “next to Video Options”).
• Accepted upcoming/past: “Report” appears in the three-dots menu.

If you want, I can add Playwright tests for these cases.

---

744-759: Menu integration looks correct and respects disabled state.

Placement after the cancel block with a separator reads well in the menu grouping.

packages/lib/server/queries/teams/index.ts (1)

430-452: LGTM: accepted-membership filter and explicit orgId guard are correct

Includes accepted: true and avoids a truthy check on organizationId. This closes the privilege leakage risk and edge cases with nullish org IDs.

packages/trpc/server/routers/viewer/bookings/reportBooking.handler.ts (1)

132-136: Single-booking re-report prevention looks good

The any-report check matches the “cannot be reported again” requirement. No action needed.

packages/trpc/server/routers/viewer/bookings/reportBooking.handler.ts (1)

155-171: Bug: recurring selection reports entire series, not “remaining occurrences”

The requirement is to report remaining occurrences from the selected instance onward. Current query omits the time filter and will also report past occurrences.

Apply this fix and keep results deterministic:

-  if (booking.recurringEventId) {
-    // Get all future bookings in the recurring series
-    const futureRecurringBookings = await prisma.booking.findMany({
-      where: {
-        recurringEventId: booking.recurringEventId,
-      },
-      select: {
-        id: true,
-      },
-    });
-
-    reportedBookingIds = futureRecurringBookings.map((b) => b.id);
-  }
+  if (booking.recurringEventId) {
+    // Get all remaining bookings in the series from this occurrence onward
+    const remainingRecurringBookings = await prisma.booking.findMany({
+      where: {
+        recurringEventId: booking.recurringEventId,
+        startTime: { gte: booking.startTime },
+      },
+      select: { id: true },
+      orderBy: { startTime: "asc" },
+    });
+    reportedBookingIds = remainingRecurringBookings.map((b) => b.id);
+  }

packages/prisma/schema.prisma (1)

764-777: One-report-per-booking enforced; drop redundant index on bookingId

• bookingId @unique correctly enforces “one report per booking” (as discussed in review threads).
• @@index([bookingId]) is redundant since a unique index already exists; remove it to avoid duplicate indexes.

Apply this diff:

 model BookingReport {
   id           String       @id @default(uuid())
   booking      Booking      @relation(fields: [bookingId], references: [id], onDelete: Cascade)
   bookingId    Int          @unique
   reportedBy   User         @relation(fields: [reportedById], references: [id], onDelete: Cascade)
   reportedById Int
   reason       ReportReason
   description  String?
   cancelled    Boolean      @default(false)
   createdAt    DateTime     @default(now())

-  @@index([bookingId])
   @@index([reportedById])
 }

apps/web/components/booking/BookingListItem.tsx (3)

86-91: Helper is fine; nit: simplify boolean

The check is correct and side-effect free. Optional: coerce to boolean for readability.

Apply this diff:

-const checkIfBookingReported = (booking: BookingItemProps): boolean => {
-  // Check if this booking has been reported by anyone
-  return booking.reports && booking.reports.length > 0;
-};
+const checkIfBookingReported = (booking: BookingItemProps): boolean =>
+  !!(booking.reports && booking.reports.length > 0);

---

430-442: Visibility rules: confirm intended UX for “Unconfirmed” tab

• Inline button shown for recurring tab items, Pending, or Cancelled.
• For “Unconfirmed” tab items with status AWAITING_HOST (not PENDING), action moves to the menu.

If design wants the inline report button to show for all “Unconfirmed” tab items (including AWAITING_HOST), expand the predicate to include isTabUnconfirmed.

Apply this minimal tweak if needed:

-const shouldShowIndividualReportButton = isTabRecurring || isPending || isCancelled;
+const shouldShowIndividualReportButton = isTabRecurring || isTabUnconfirmed || isPending || isCancelled;

---

798-812: Avoid over-invalidating cache

utils.viewer.bookings.invalidate() is sufficient to reflect reporting changes on list items. utils.invalidate() is heavy and can regress performance.

Apply this diff:

 onSuccess={async () => {
   // Invalidate all booking queries to ensure UI reflects the changes
   await utils.viewer.bookings.invalidate();
-  // Also invalidate any cached booking data
-  await utils.invalidate();
 }}

packages/trpc/server/routers/viewer/bookings/reportBooking.handler.ts (1)

186-207: Cancellation integration LGTM; optional: gate on created reports

Minor consideration: if another concurrent request already reported (createMany.count = 0), you may still proceed to cancel here. If product expects cancellation to occur only when a report is actually recorded by this request, gate on createdCount > 0 before calling handleCancelBooking.

-  if (
+  if (
     cancelBooking &&
     (booking.status === BookingStatus.ACCEPTED || booking.status === BookingStatus.PENDING) &&
     new Date(booking.startTime) > new Date()
   ) {
+    // Optional: only cancel if this request created at least one report
+    // if (createResult.count === 0) { /* skip cancel */ } else { ... }
     try {
       await handleCancelBooking({

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: supalarry
PR: calcom/cal.com#23217
File: apps/api/v2/src/ee/event-types/event-types_2024_06_14/services/output-event-types.service.ts:93-94
Timestamp: 2025-08-21T13:44:06.784Z
Learning: In apps/api/v2/src/ee/event-types/event-types_2024_06_14/event-types.repository.ts, repository functions that use explicit Prisma select clauses (like getEventTypeWithSeats) are used for specific purposes and don't need to include all EventType fields like bookingRequiresAuthentication. These methods don't feed into the general OutputEventTypesService_2024_06_14 flow.

Learnt from: CR
PR: calcom/cal.com#0
File: .cursor/rules/review.mdc:0-0
Timestamp: 2025-07-28T11:50:23.946Z
Learning: Applies to **/*.ts : For Prisma queries, only select data you need; never use `include`, always use `select`

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.

Learnt from: eunjae-lee
PR: calcom/cal.com#23166
File: packages/prisma/migrations/20250818151914_routing_form_response_denormalized_backfill2/migration.sql:65-66
Timestamp: 2025-08-19T09:47:49.478Z
Learning: The Booking table has a unique constraint and index on the uid column (defined as `uid String unique` in schema.prisma), so JOINs on Booking.uid have optimal performance and don't require additional indexing.

Learnt from: eunjae-lee
PR: calcom/cal.com#22106
File: packages/features/insights/components/FailedBookingsByField.tsx:65-71
Timestamp: 2025-07-15T12:59:34.389Z
Learning: In the FailedBookingsByField component (packages/features/insights/components/FailedBookingsByField.tsx), although routingFormId is typed as optional in useInsightsParameters, the system automatically enforces a routing form filter, so routingFormId is always present in practice. This means the data always contains only one entry, making the single-entry destructuring approach safe.

Learnt from: alishaz-polymath
PR: calcom/cal.com#23247
File: packages/features/webhooks/lib/factory/WebhookPayloadFactory.ts:274-282
Timestamp: 2025-08-21T12:28:42.000Z
Learning: In BookingPaymentInitiatedDTO and other webhook DTOs in packages/features/webhooks/lib/dto/types.ts, the booking field is a restricted structure containing only specific fields (id, eventTypeId, userId) rather than the full database booking object, so there are no security or PII leakage concerns when passing the booking object to buildEventPayload.

Learnt from: alishaz-polymath
PR: calcom/cal.com#23247
File: packages/features/webhooks/lib/factory/WebhookPayloadFactory.ts:274-282
Timestamp: 2025-08-21T12:28:42.000Z
Learning: In webhook DTOs in packages/features/webhooks/lib/dto/types.ts, the booking fields are restricted structures containing only specific fields (id, eventTypeId, userId, and sometimes additional fields like startTime or smsReminderNumber) rather than full database booking objects, so there are no security or PII leakage concerns when using these booking objects in webhook payloads.

packages/prisma/schema.prisma (3)

758-763: Enum looks good; mapping aligns with i18n usage

The ReportReason enum and @Map for DONT_KNOW_PERSON are appropriate. This keeps DB values stable and matches UI keys like "dont_know_person".

---

448-449: Relation on User is appropriate

bookingReports on User allows “my reports” queries without backtracking from Booking. All good.

---

845-846: Relation on Booking is consistent with UI needs

reports on Booking supports UI badge logic. Even though bookingId is unique (1:1), keeping this as a list is fine given existing frontend expectations.

apps/web/components/booking/BookingListItem.tsx (5)

141-141: State for dialog LGTM

Local dialog state is appropriate here.

---

409-412: Memoization is acceptable

Memo on booking object is fine given you invalidate/refetch on change. No concerns.

---

413-429: Action factory reads well; consistent labels/icons

The helper avoids duplication between inline button and dropdown item. Good use of t().

---

744-759: Dropdown action wiring LGTM

Action is appended after existing sections and respects disabled state when already reported.

---

765-779: Inline icon action LGTM

Good use of tooltip via label; respects disabled state when already reported.

packages/trpc/server/routers/viewer/bookings/reportBooking.handler.ts (4)

26-60: Good: precise Prisma select; complies with data-minimization guideline

Using select (not include) and limiting to necessary fields is aligned with our TS/Prisma guidelines.

---

137-154: Series-level duplicate guard is fine

Preventing a second report on the same recurring series matches the one-report-per-series intention.

---

172-183: Good concurrency handling

createMany with skipDuplicates avoids unique-constraint races and you correctly use result.count in the response.

---

209-223: Clear, user-facing messaging

Good job reflecting series vs single and surfacing cancellation failure without blocking the report.

packages/trpc/server/routers/viewer/bookings/reportBooking.handler.ts (4)

128-131: Access gate correctly considers admin/owner status

Including isTeamAdminOrOwner in the final access check fixes the earlier edge case where admins could be denied if the org-filter yielded no memberships.

---

158-169: Good: remaining-occurrence scoping for recurring bookings

Filtering by startTime >= the selected instance and ordering asc matches “report remaining occurrences” reliably.

---

171-181: Good: createMany with skipDuplicates to handle concurrency

This prevents duplicate reports under concurrent submissions.

---

208-221: Good: response messaging uses actual inserted count and surfaces cancellation errors

Accurately reporting createdCount and exposing cancellationError improves UX and debuggability.

packages/trpc/server/routers/viewer/bookings/reportBooking.handler.ts (7)

26-60: Prune unused selections in booking.select to reduce payload and query cost

You only use eventType.teamId later; the nested team fields (id, name, parentId) are unused. Drop them to adhere to “select only what you need” and keep the payload lean.

Apply this diff:

       eventType: {
         select: {
-          teamId: true,
-          team: {
-            select: {
-              id: true,
-              name: true,
-              parentId: true,
-            },
-          },
+          teamId: true,
         },
       },

---

66-68: Make attendee email check case-insensitive

Email addresses are case-insensitive; strict equality can deny legitimate attendees. Compare lowercased values to avoid false negatives.

-  const isAttendee = booking.attendees.some((attendee) => attendee.email === user.email);
+  const isAttendee = booking.attendees.some(
+    (attendee) => attendee.email?.toLowerCase() === user.email?.toLowerCase()
+  );

---

81-126: Scope team-member email query to relevant addresses to avoid scanning large orgs

Fetching all team member emails across all admin-owned teams doesn’t scale. Limit the query to the booking owner + attendee emails; this materially reduces rows scanned and memory.

-    // Get all team member emails where user is admin/owner
-    const teamMemberEmails = await prisma.user.findMany({
-      where: {
-        teams: {
-          some: {
-            team: {
-              members: {
-                some: {
-                  id: { in: membershipIdsWhereUserIsAdminOwner },
-                },
-              },
-            },
-          },
-        },
-      },
-      select: {
-        email: true,
-      },
-    });
+    // Get the booking owner's email once
+    const bookingOwnerEmail =
+      booking.userId
+        ? (await prisma.user.findUnique({ where: { id: booking.userId }, select: { email: true } }))?.email
+        : undefined;
+
+    const candidateEmails = [
+      ...booking.attendees.map((a) => a.email),
+      ...(bookingOwnerEmail ? [bookingOwnerEmail] : []),
+    ];
+
+    // Only fetch users relevant to this booking within teams where the requester is ADMIN/OWNER
+    const teamMemberEmails = await prisma.user.findMany({
+      where: {
+        email: { in: candidateEmails },
+        teams: {
+          some: {
+            team: {
+              members: { some: { id: { in: membershipIdsWhereUserIsAdminOwner } } },
+            },
+          },
+        },
+      },
+      select: { email: true },
+    });
@@
-    // Check if booking owner is a team member where user is admin/owner
-    let isBookingOwnerTeamMember = false;
-    if (booking.userId) {
-      const bookingOwner = await prisma.user.findUnique({
-        where: { id: booking.userId },
-        select: { email: true },
-      });
-      isBookingOwnerTeamMember = !!(bookingOwner && teamMemberEmailList.includes(bookingOwner.email));
-    }
+    // Check if booking owner is a team member where user is admin/owner
+    const isBookingOwnerTeamMember = bookingOwnerEmail
+      ? teamMemberEmailList.includes(bookingOwnerEmail)
+      : false;

Note: Nice job already following the “use select, not include” guideline; this change just tightens the scope further.

---

185-206: Update the “cancelled” flag on BookingReport to reflect actual outcome

Reports are inserted before cancellation and persisted with cancelled: cancelBooking even if the cancellation fails. If “cancelled” is meant to represent the actual result, add a follow-up update to reflect the outcome.

   } catch (error) {
     cancellationError = error;
     console.error("Failed to cancel booking after reporting:", error);
   }
 }
+
+// Reflect actual cancellation outcome on the report(s)
+await prisma.bookingReport.updateMany({
+  where: {
+    bookingId: { in: reportedBookingIds },
+    reportedById: user.id,
+  },
+  data: {
+    cancelled: cancelBooking && !cancellationError,
+  },
+});

If “cancelled” is intended to mean “cancellation requested,” consider renaming to cancelRequested in a follow-up migration to avoid ambiguity.

---

186-191: Nit: compute ‘now’ once for consistent comparison and micro-alloc reduction

Minor, but avoids constructing multiple Date instances.

-  if (
+  const now = new Date();
+  if (
     cancelBooking &&
     (booking.status === BookingStatus.ACCEPTED || booking.status === BookingStatus.PENDING) &&
-    new Date(booking.startTime) > new Date()
+    new Date(booking.startTime) > now
   ) {

---

203-205: Prefer centralized/structured logging over console.error

Route logs through the project’s logging facility (if available) for consistency and observability.

---

183-184: Nit: avoid temporary object for reportedBooking

You can pass the id directly; the object wrapper isn’t needed.

-  const reportedBooking = { id: reportedBookingIds[0] };
+  const firstReportedBookingId = reportedBookingIds[0];
@@
-    bookingId: reportedBooking.id,
+    bookingId: firstReportedBookingId,

Also applies to: 219-220

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: supalarry
PR: calcom/cal.com#23217
File: apps/api/v2/src/ee/event-types/event-types_2024_06_14/services/output-event-types.service.ts:93-94
Timestamp: 2025-08-21T13:44:06.784Z
Learning: In apps/api/v2/src/ee/event-types/event-types_2024_06_14/event-types.repository.ts, repository functions that use explicit Prisma select clauses (like getEventTypeWithSeats) are used for specific purposes and don't need to include all EventType fields like bookingRequiresAuthentication. These methods don't feed into the general OutputEventTypesService_2024_06_14 flow.

Learnt from: CR
PR: calcom/cal.com#0
File: .cursor/rules/review.mdc:0-0
Timestamp: 2025-07-28T11:50:23.946Z
Learning: Applies to **/*.ts : For Prisma queries, only select data you need; never use `include`, always use `select`

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.

packages/trpc/server/routers/viewer/bookings/reportBooking.handler.ts (3)

137-153: Series-level dedupe may be too aggressive—confirm product intent

Current check blocks reporting if any instance in the series has been reported, even if that report was for a past occurrence. The spec says “Reported bookings cannot be reported again,” but it’s ambiguous at the series level.

• If the intent is to prevent duplicate reports only for remaining occurrences, scope the check to bookings with startTime >= the selected instance.
• If the intent is “once per series ever,” keep as-is.

Optional change if you want “remaining occurrences only”:

-  const existingRecurringReport = await prisma.bookingReport.findFirst({
-    where: {
-      booking: {
-        recurringEventId: booking.recurringEventId,
-      },
-    },
-  });
+  const existingRecurringReport = await prisma.bookingReport.findFirst({
+    where: {
+      booking: {
+        recurringEventId: booking.recurringEventId,
+        startTime: { gte: booking.startTime },
+      },
+    },
+  });

---

171-181: Ensure DB has a unique index to make skipDuplicates effective

skipDuplicates only works if there’s a backing unique index (likely on bookingId if “only one report per booking” is desired). Please confirm the migration adds it; otherwise duplicates can still occur.

If needed, add a unique constraint (migration-level):

• Unique on bookingId (series-level single report) or
• Unique on (bookingId, reportedById) (per-reporter dedupe)

Align with product choice.

---

193-201: Good: fromReport + allRemainingBookings flags align with UX and email requirements

Bypassing a cancellation reason and letting the standard cancellation email send (without mentioning “reported”) meets the product requirement.