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

apps/api/v2/src/modules/slots/slots-2024-09-04/services/slots.service.spec.ts (1)

14-18: Remove redundant jest.mock for AvailableSlotsService

You already provide AvailableSlotsService via Nest DI with a useValue mock below. The top-level jest.mock here is redundant and risks diverging behavior if the service’s shape changes. Rely on the DI-provided mock only.

-jest.mock("@/lib/services/available-slots.service", () => ({
-  AvailableSlotsService: jest.fn().mockImplementation(() => ({
-    getAvailableSlots: jest.fn(),
-  })),
-}));

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

apps/api/v2/src/modules/auth/strategies/api-auth/api-auth.strategy.e2e-spec.ts (2)

12-12: ProfilesModule may be redundant now—verify and remove if unused.

Profiles are no longer part of the owner lookup in this strategy. If nothing else in this spec requires Nest DI from ProfilesModule (fixtures usually talk directly to Prisma), drop it to reduce bootstrap time and stale dependencies.

Also applies to: 67-67

---

298-305: Tighten teardown: delete org2 and client2; await module.close for clean shutdown.

Avoids leftover records and unawaited async cleanup in Jest/Nest.

   afterAll(async () => {
     await oAuthClientRepositoryFixture.delete(oAuthClient.id);
+    await oAuthClientRepositoryFixture.delete(oAuthClientTwo.id);
     await userRepositoryFixture.delete(validApiKeyUser.id);
     await userRepositoryFixture.delete(validAccessTokenUser.id);
     await userRepositoryFixture.delete(validOAuthUser.id);
     await teamRepositoryFixture.delete(organization.id);
-    module.close();
+    await teamRepositoryFixture.delete(organizationTwo.id);
+    await module.close();
   });

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.

apps/api/v2/src/modules/auth/strategies/api-auth/api-auth.strategy.e2e-spec.ts (2)

7-7: Importing MembershipsModule is the right move to align DI with the new owner-resolution path.

This ensures the strategy can resolve the owner via MembershipsRepository at runtime in tests.

---

187-205: OAuth-client assertions remain valid once OWNER memberships are seeded.

No assertion change needed, but without the new memberships the test will 401 with “No owner ID found…”.

apps/api/v2/src/modules/auth/strategies/api-auth/api-auth.strategy.e2e-spec.ts (1)

24-24: Correct fixture import (singular) — aligns with existing test fixtures

Path and name now match the actual fixture. This addresses the earlier feedback about the plural form.

apps/api/v2/src/modules/auth/strategies/api-auth/api-auth.strategy.e2e-spec.ts (1)

129-135: OWNER memberships seeded — required for OAuth-client flow; consider minor cleanups

Seeding accepted OWNER memberships is exactly what the new logic needs. Two small, optional improvements:

• Prefer direct FKs over nested connect for brevity (fixture accepts Prisma.MembershipCreateInput either way).
• Add explicit cleanup for created entities to reduce DB litter and avoid relying on cascades.

Apply this minimal diff to use direct FKs:

-    await membershipRepositoryFixture.create({
-      user: { connect: { id: validOAuthUser.id } },
-      team: { connect: { id: organization.id } },
-      role: "OWNER",
-      accepted: true,
-    });
+    await membershipRepositoryFixture.create({
+      userId: validOAuthUser.id,
+      teamId: organization.id,
+      role: "OWNER",
+      accepted: true,
+    });

-    await membershipRepositoryFixture.create({
-      user: { connect: { id: validOAuthUser.id } },
-      team: { connect: { id: organizationTwo.id } },
-      role: "OWNER",
-      accepted: true,
-    });
+    await membershipRepositoryFixture.create({
+      userId: validOAuthUser.id,
+      teamId: organizationTwo.id,
+      role: "OWNER",
+      accepted: true,
+    });

Additionally, consider explicitly deleting org2 in teardown (and/or membership rows) so this spec doesn’t leave residue:

@@
   afterAll(async () => {
     await oAuthClientRepositoryFixture.delete(oAuthClient.id);
     await userRepositoryFixture.delete(validApiKeyUser.id);
     await userRepositoryFixture.delete(validAccessTokenUser.id);
     await userRepositoryFixture.delete(validOAuthUser.id);
     await teamRepositoryFixture.delete(organization.id);
+    await teamRepositoryFixture.delete(organizationTwo.id);
     module.close();
   });

Optional coverage follow-up: add a test for the ADMIN fallback (when OWNER is absent) to exercise the new repository method chain (findPlatformOwnerUserId → findPlatformAdminUserId). I can draft that if useful.

Also applies to: 136-142

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.

apps/api/v2/src/modules/auth/strategies/api-auth/api-auth.strategy.e2e-spec.ts (4)

7-7: Good call: Importing MembershipsModule makes DI consistent with the new lookup path

This ensures the strategy’s dependencies (via MembershipsRepository) are available in the test module.

---

50-50: Fixture handle added

The dedicated fixture handle keeps setup clear and mirrors other repository fixtures.

---

71-71: MembershipsModule registered in the TestingModule

Matches the strategy change to membership-based owner resolution.

---

98-98: Fixture wiring looks correct

Instantiating MembershipRepositoryFixture from the compiled module follows the same pattern as other fixtures.

apps/api/v2/src/app.e2e-spec.ts (1)

113-120: Ensure role typing via enum to avoid stringly-typed regressions.

Using the enum eliminates typos and keeps parity with Prisma types.

Apply within this block:

-        role: "OWNER",
+        role: MembershipRole.OWNER,

Add this import near existing Prisma imports:

import { MembershipRole } from "@calcom/prisma/client";

Optional: if any provider caches memberships at bootstrap in the future, consider creating the membership before creating the OAuth client to make test intent explicit. No change required now.

apps/api/v2/src/modules/oauth-clients/controllers/oauth-flow/oauth-flow.controller.e2e-spec.ts (1)

111-116: Creating an accepted OWNER membership is essential; switch to enum and consider minor hardening.

• Type-safe role protects against typos.
• Optional: assert the create() returns an id to fail fast if setup changes.

Apply within this block:

-        role: "OWNER",
+        role: MembershipRole.OWNER,

Add this import near existing Prisma imports:

import { MembershipRole } from "@prisma/client";

If you want a quick assertion:

const membership = await membershipRepositoryFixture.create({ /* ... */ });
expect(membership?.id).toBeDefined();

Also consider adding a separate test where OWNER is absent but ADMIN exists to validate the fallback introduced in ApiAuthStrategy.

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.

apps/api/v2/src/app.e2e-spec.ts (2)

12-12: Importing MembershipRepositoryFixture is the right move for OWNER-based resolution.

This aligns the e2e with the new Memberships-based owner lookup. No issues spotted.

---

37-37: Fixture variable addition is fine.

Naming is consistent with the other fixtures and keeps setup readable.

apps/api/v2/src/modules/oauth-clients/controllers/oauth-flow/oauth-flow.controller.e2e-spec.ts (3)

18-18: Importing MembershipRepositoryFixture is necessary for the new flow.

Matches the refactor to OWNER-based platform owner detection.

---

67-67: Fixture variable addition looks good.

Keeps test setup aligned with repository fixtures.

---

94-95: No caching detected—post-init membership fixture is safe.

I searched the ApiAuthStrategy, application modules, the memberships repository, and the MembershipRepositoryFixture for any caching configuration or keywords (e.g. CacheModule, CacheInterceptor, “cache”) and found none. There’s no bootstrap-time or request-scope caching that would interfere with resolving the owner per request, so initializing the membership fixture after app.init() poses no risk.