packages/prisma/schema/commission.prisma (1)

48-58: New (programId, createdAt, id) index aligns with cursor-pagination access pattern

This index matches the expected ordering for cursor-based pagination by createdAt with id as a tiebreaker under a given programId, which should improve query performance and stability. You still retain the more complex [programId, createdAt, status, amount, earnings] index for other queries; you can revisit index overlap later if needed.

apps/web/lib/zod/schemas/links.ts (1)

7-18: Cursor + deprecated page-based pagination composition in getLinksQuerySchemaBase looks sound

Merging getCursorPaginationQuerySchema ahead of the deprecated getPaginationQuerySchema cleanly exposes both cursor params (startingAfter, endingBefore) and legacy page/pageSize, which matches how getPaginationOptions expects filters.

One minor follow-up to consider: linksExportQuerySchema omits page and pageSize but still inherits startingAfter/endingBefore from getLinksQuerySchemaBase. If the export endpoint never uses cursor pagination, you might want to omit those as well for clearer docs and validation, or explicitly document that they’re ignored for exports.

Also applies to: 160-179, 272-292

apps/web/lib/zod/schemas/customers.ts (1)

1-8: Customers query schema now cleanly supports cursor + deprecated page-based pagination

getCustomersQuerySchema correctly layers:

• core filters and sort fields,
• cursor pagination (startingAfter / endingBefore with a concrete example), and
• deprecated page-based pagination with CUSTOMERS_MAX_PAGE_SIZE.

That matches the expectations of getPaginationOptions and clearly nudges clients towards cursor-based pagination.

For getCustomersCountQuerySchema, you omit page, pageSize, sortBy, and sortOrder, but cursor params still pass through. If the /customers/count endpoint never uses cursors, you might eventually tighten this by omitting startingAfter/endingBefore as well so the count contract is unambiguously “no pagination here”.

Also applies to: 13-73, 85-93

apps/web/lib/zod/schemas/commissions.ts (1)

131-136: Consider omitting cursor fields from count/export query schemas (optional)

getCommissionsCountQuerySchema and commissionsExportQuerySchema still allow startingAfter / endingBefore via getCommissionsQuerySchema, but those values are typically irrelevant for a global count or full export. If these endpoints never use cursor pagination, consider omitting cursor fields here as well to make the API surface clearer and avoid confusing no-op parameters.

Also applies to: 301-325

apps/web/tests/customers/pagination.test.ts (2)

18-30: Tests assume at least 10 customers in the E2E workspace

Several tests access baseline[4], baseline[5], and compare slices up to index 10. This is fine with the current seeded data, but will start failing if the fixture workspace ever has fewer than 10 customers. If you want the suite to be more robust to fixture changes, you could either seed the required minimum inside the tests or explicitly assert baseline.length >= 10 with a clear failure message.

Also applies to: 32-78, 163-255

---

258-277: Deduplicate pagination helper assertions across test suites (optional)

expectSortedByCreatedAt, expectSortedByCreatedAtAsc, and expectNoOverlap are mirrored in the commissions pagination tests. Consider moving these helpers into a shared test utility (for example under tests/utils/pagination.ts) to avoid duplication and keep future changes to pagination assertions in one place.

apps/web/lib/api/links/get-links-for-workspace.ts (1)

17-39: Relying on parsed filters for pagination fields (optional clarification)

getPaginationOptions assumes page, pageSize, sortBy, and sortOrder are present and valid on filters. As long as all callers pass in objects produced by getLinksQuerySchemaExtended.parse, that’s guaranteed via Zod defaults and enums. If this function is ever reused with unvalidated inputs, you may want to either export and reuse the Filters type from pagination.ts or document that pre-validation is required.

Also applies to: 156-157

apps/web/lib/api/pagination.ts (1)

4-20: Document or generalize the id-based cursor assumption (optional)

PaginationOptions.cursor and the secondary orderBy key are hard-coded to id, which matches your current models but is an implicit requirement. If you ever paginate on a model whose cursor column is not id, you’ll need to extend this helper. Consider either documenting this assumption in a comment or parameterizing the cursor field name in the future.

Also applies to: 24-55

apps/web/lib/zod/schemas/misc.ts (1)

31-66: Optional: push mutual-exclusion check into Zod as well

You currently enforce startingAfter / endingBefore mutual exclusivity in getPaginationOptions, which is sufficient for runtime behavior. If you want clients of the Zod schema alone (e.g. non-HTTP callers) to see validation errors earlier, you could add a .refine on getCursorPaginationQuerySchema to reject payloads that specify both fields.

Also applies to: 68-93

apps/web/tests/commissions/pagination.test.ts (2)

18-29: Tests rely on having at least 10 commissions in the E2E workspace

As with the customers suite, several expectations depend on baseline[4], baseline[5], and slices up to index 10. That’s fine with current fixtures but will break if the seeded workspace ever has fewer commissions. If you’d like these tests to be more resilient, you could either seed the necessary minimum inside the suite or assert baseline.length >= 10 with a clear failure reason.

Also applies to: 31-77, 180-280

---

283-302: Extract shared pagination assertion helpers (optional)

expectSortedByCreatedAt, expectSortedByCreatedAtAsc, and expectNoOverlap are duplicated from the customers pagination tests. Pulling them into a shared test helper module would reduce duplication and keep pagination-specific assertions consistent across suites.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: TWilson023
Repo: dubinc/dub PR: 2872
File: packages/prisma/schema/partner.prisma:151-153
Timestamp: 2025-09-24T16:13:00.387Z
Learning: In the Dub codebase, Prisma schemas use single-column indexes without brackets (e.g., `@index(partnerId)`) and multi-column indexes with brackets (e.g., `@index([programId, partnerId])`). This syntax pattern is consistently used throughout their schema files and works correctly with their Prisma version.

Learnt from: devkiran
Repo: dubinc/dub PR: 2177
File: apps/web/lib/api/links/bulk-create-links.ts:66-84
Timestamp: 2025-06-06T07:59:03.120Z
Learning: In apps/web/lib/api/links/bulk-create-links.ts, the team accepts the risk of potential undefined results from links.find() operations when building invalidLinks arrays, because existing links are fetched from the database based on the input links, so matches are expected to always exist.

Learnt from: TWilson023
Repo: dubinc/dub PR: 2935
File: packages/prisma/schema/workspace.prisma:21-36
Timestamp: 2025-10-06T15:48:45.956Z
Learning: In the Dub repository (dubinc/dub), Prisma schema changes are not managed with separate migration files. Do not flag missing Prisma migration files when schema changes are made to files like `packages/prisma/schema/workspace.prisma` or other schema files.

Learnt from: devkiran
Repo: dubinc/dub PR: 0
File: :0-0
Timestamp: 2025-10-17T08:18:19.278Z
Learning: In the apps/web codebase, `@/lib/zod` should only be used for places that need OpenAPI extended zod schema. All other places should import from the standard `zod` package directly using `import { z } from "zod"`.

apps/web/tests/customers/pagination.test.ts (1)

52-65: Consider adding explicit sort parameters for deterministic results.

The cursor-based pagination tests (lines 52-65, 67-79, 138-149, 152-162) omit sortBy and sortOrder parameters while comparing results against a baseline fetched with explicit sortBy: "createdAt" and sortOrder: "desc". If the API's default sort order differs or changes, these tests could become flaky.

For example, update the startingAfter test:

 test("Cursor forward (startingAfter)", async () => {
   const firstPage = baseline.slice(0, 5);
   const lastId = firstPage[4].id;

   const { status, data } = await http.get<Customer[]>({
     path: "/customers",
-    query: { pageSize: "5", startingAfter: lastId },
+    query: { 
+      pageSize: "5", 
+      startingAfter: lastId,
+      sortBy: "createdAt",
+      sortOrder: "desc"
+    },
   });

   expect(status).toEqual(200);
   expectSortedByCreatedAt(data);

   expect(data.map((c) => c.id)).toEqual(baselineIds.slice(5, 10));
 });

Apply similar changes to the other cursor-based tests for consistency.

Also applies to: 67-79, 138-149, 152-162

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro