Code Review Bench PR #26717 - refactor: Remove trpc/server dependency from @calcom/atoms

[ketkarameya]

Benchmark PR for Gitar evaluation

Original PR: agentic-review-benchmarks#15

refactor: Remove trpc/server dependency from @calcom/atoms

---

Summary by Gitar

• Type consistency refactor:
  • Changed userIds and fromUser.id from number to string in packages/platform/atoms/booker/types.ts
  • Changed days from number[] to string[] in packages/platform/atoms/hooks/schedules/types.ts
• New validation helper:
  • validateCreateScheduleInput in packages/platform/atoms/hooks/schedules/types.ts provides runtime validation for schedule creation

_{This will update automatically on new commits.}

---

[gitar-bot-staging]

🚨 Bug: days: string[] contradicts Prisma schema days Int[]

The Prisma schema defines Availability.days as Int[] (see packages/prisma/schema.prisma), and every other usage in the codebase types days as number[] (e.g., packages/lib/schedules/transformers/getScheduleListItemData.ts, packages/types/schedule.d.ts, packages/platform/atoms/availability/AvailabilitySettings.tsx, packages/platform/atoms/availability/types.ts, packages/features/availability/lib/getUserAvailability.ts).

Changing this to string[] in the atoms package creates a type mismatch between what the API/database actually returns (integer arrays like [0, 1, 2, 3, 4] for weekdays) and what this type declares. This will cause TypeScript compilation errors or silent type unsafety at the boundary where this data is consumed.

_{Was this helpful? React with 👍 / 👎}

Suggested change

	days: string[];
	days: number[];

• Apply suggested fix

[gitar-bot-staging]

🚨 Bug: fromUser.id: string contradicts source IFromUser.id: number

The SlotInfo.fromUser.id field is typed as string, but the source of truth IFromUser interface in packages/features/availability/lib/getUserAvailability.ts defines id: number. The slot data flows from getUserAvailability → slots.ts → the API response, and at every step the fromUser.id is a numeric user ID from the database.

Interestingly, toUser.id on the very next line in the same SlotInfo type is correctly typed as number, making this an internal inconsistency. This will cause consumers of the atoms package to expect a string where a number is actually returned, leading to subtle bugs (e.g., fromUser.id === someStringId would fail with strict equality).

_{Was this helpful? React with 👍 / 👎}

Suggested change

	id: string;
	id: number;

• Apply suggested fix

[gitar-bot-staging]

🚨 Bug: Slot.userIds: string[] contradicts upstream number[] type

The Slot.userIds field was changed from number[] to string[], but the upstream code that produces this data (in packages/features/schedules/lib/slots.ts) consistently types userIds as number[]. The TimeFrame type is { userIds?: number[]; startTime: number; endTime: number }, and all slot generation code works with numeric user IDs.

The original type in packages/trpc/server/routers/viewer/slots/types.ts (being deleted in this PR) had userIds?: number[]. Changing this to string[] in the atoms package means the type no longer matches the actual runtime data, which will cause type errors for any code that tries to use both the atom types and the internal slot types together (e.g., apps/web/test/lib/getSchedule/expects.ts which now imports from @calcom/atoms/booker/types).

_{Was this helpful? React with 👍 / 👎}

Suggested change

	userIds?: string[];
	userIds?: number[];

• Apply suggested fix

[gitar-bot-staging]

⚠️ Edge Case: validateCreateScheduleInput doesn't validate schedule or eventTypeId

The validation function only checks that name is a non-empty string, then casts the entire object to CreateScheduleInput via as. This means the schedule and eventTypeId fields are completely unvalidated — a caller could pass { name: "foo", schedule: "not-an-array", eventTypeId: "not-a-number" } and it would be returned as a valid CreateScheduleInput.

The original implementation used a Zod schema (ZCreateInputSchema) that validated all fields including the nested schedule array structure (z.array(z.array(z.object({ start: z.date(), end: z.date() })))) and eventTypeId as z.number().optional().

Since this function's purpose is to provide runtime validation for external npm package consumers, the unsafe as cast defeats that goal. Consider either:

1. Adding validation for schedule and eventTypeId fields
2. Documenting that only name is validated
3. Using a schema validation library (the atoms package could add a lightweight one)

_{Was this helpful? React with 👍 / 👎}

• Apply suggested fix

[gitar-bot-staging]

⚠️ Bug: Package export changed from ./booker to ./booker/types (breaking)

The package.json exports map was changed from "./booker": "./booker/index.ts" to "./booker/types": "./booker/types.ts". This is a breaking change for any external consumer of the @calcom/atoms npm package who imports from @calcom/atoms/booker.

While the test file in this repo (apps/web/test/lib/getSchedule/expects.ts) was updated to use the new path @calcom/atoms/booker/types, external consumers won't get that update automatically. Since @calcom/atoms is a published npm package (currently at v2.2.0), this would require a major version bump per semver conventions.

Note: If the ./booker export was only used internally and the main "." export already re-exports the booker module, this may be less impactful. But as written, this removes a previously available import path.

_{Was this helpful? React with 👍 / 👎}

• Apply suggested fix

[gitar-bot-staging]

⚠️ This PR is blocked due to unresolved code review findings.

_{Configure merge blocking · Maintainers can dismiss this review. Gitar never approves changes.}

[gitar-bot-staging]

Code Review 🚫 Blocked 0 resolved / 5 findings

Three type changes (userIds, fromUser.id, days) contradict their upstream source types (Prisma schema and feature interfaces all use number). The package export rename from ./booker to ./booker/types is a breaking change for external consumers. The validation function only validates name while performing an unsafe cast on the rest of the input.

🚨 Bug: days: string[] contradicts Prisma schema days Int[]

📄 packages/platform/atoms/hooks/schedules/types.ts:22

The Prisma schema defines Availability.days as Int[] (see packages/prisma/schema.prisma), and every other usage in the codebase types days as number[] (e.g., packages/lib/schedules/transformers/getScheduleListItemData.ts, packages/types/schedule.d.ts, packages/platform/atoms/availability/AvailabilitySettings.tsx, packages/platform/atoms/availability/types.ts, packages/features/availability/lib/getUserAvailability.ts).

Changing this to string[] in the atoms package creates a type mismatch between what the API/database actually returns (integer arrays like [0, 1, 2, 3, 4] for weekdays) and what this type declares. This will cause TypeScript compilation errors or silent type unsafety at the boundary where this data is consumed.

Suggested fix

      days: number[];

🚨 Bug: fromUser.id: string contradicts source IFromUser.id: number

📄 packages/platform/atoms/booker/types.ts:121

The SlotInfo.fromUser.id field is typed as string, but the source of truth IFromUser interface in packages/features/availability/lib/getUserAvailability.ts defines id: number. The slot data flows from getUserAvailability → slots.ts → the API response, and at every step the fromUser.id is a numeric user ID from the database.

Interestingly, toUser.id on the very next line in the same SlotInfo type is correctly typed as number, making this an internal inconsistency. This will cause consumers of the atoms package to expect a string where a number is actually returned, leading to subtle bugs (e.g., fromUser.id === someStringId would fail with strict equality).

Suggested fix

    id: number;

🚨 Bug: Slot.userIds: string[] contradicts upstream number[] type

📄 packages/platform/atoms/booker/types.ts:19

The Slot.userIds field was changed from number[] to string[], but the upstream code that produces this data (in packages/features/schedules/lib/slots.ts) consistently types userIds as number[]. The TimeFrame type is { userIds?: number[]; startTime: number; endTime: number }, and all slot generation code works with numeric user IDs.

The original type in packages/trpc/server/routers/viewer/slots/types.ts (being deleted in this PR) had userIds?: number[]. Changing this to string[] in the atoms package means the type no longer matches the actual runtime data, which will cause type errors for any code that tries to use both the atom types and the internal slot types together (e.g., apps/web/test/lib/getSchedule/expects.ts which now imports from @calcom/atoms/booker/types).

Suggested fix

  userIds?: number[];

⚠️ Edge Case: validateCreateScheduleInput doesn't validate schedule or eventTypeId

📄 packages/platform/atoms/hooks/schedules/types.ts:38

The validation function only checks that name is a non-empty string, then casts the entire object to CreateScheduleInput via as. This means the schedule and eventTypeId fields are completely unvalidated — a caller could pass { name: "foo", schedule: "not-an-array", eventTypeId: "not-a-number" } and it would be returned as a valid CreateScheduleInput.

The original implementation used a Zod schema (ZCreateInputSchema) that validated all fields including the nested schedule array structure (z.array(z.array(z.object({ start: z.date(), end: z.date() })))) and eventTypeId as z.number().optional().

Since this function's purpose is to provide runtime validation for external npm package consumers, the unsafe as cast defeats that goal. Consider either:

1. Adding validation for schedule and eventTypeId fields
2. Documenting that only name is validated
3. Using a schema validation library (the atoms package could add a lightweight one)

⚠️ Bug: Package export changed from ./booker to ./booker/types (breaking)

📄 packages/platform/atoms/package.json:58

The package.json exports map was changed from "./booker": "./booker/index.ts" to "./booker/types": "./booker/types.ts". This is a breaking change for any external consumer of the @calcom/atoms npm package who imports from @calcom/atoms/booker.

While the test file in this repo (apps/web/test/lib/getSchedule/expects.ts) was updated to use the new path @calcom/atoms/booker/types, external consumers won't get that update automatically. Since @calcom/atoms is a published npm package (currently at v2.2.0), this would require a major version bump per semver conventions.

Note: If the ./booker export was only used internally and the main "." export already re-exports the booker module, this may be less impactful. But as written, this removes a previously available import path.

Rules 🎸 1 action taken

Gitar Rules

🎸 Summary Enhancement: Appended 'Summary by Gitar' section with 2 technical bullets covering type refactoring and validation helper

_{5 rules not applicable. Show all rules by commenting gitar display:verbose.}

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}