fix(orm): _count is not included in select clause's typing when querying from a to-one relation

[ymc9]

#2343

Summary by CodeRabbit

• Bug Fixes

  • Fixed type behavior for include/omit operations to work consistently in all query contexts.

• Tests

  • Added TypeScript type-checking coverage for relation counting functionality in queries.

[claude]

Claude finished @ymc9's task —— View job

---

Code Review

Todo List:

• Read modified files to understand the changes
• Analyze the type fix for correctness
• Review test coverage adequacy
• Check for potential issues or edge cases
• Provide comprehensive feedback

Summary

This PR fixes a TypeScript typing issue where _count was not properly included in select clauses when querying from to-one relations. The fix is minimal but correctly addresses the root cause.

Analysis

The Problem: The FindArgs type definition in line 1218 was incorrectly using the Collection generic parameter for the AllowCount parameter of SelectIncludeOmit, which evaluates to false for single-item queries (like findUnique, findFirst). This prevented _count from being available in the TypeScript types when selecting fields in to-one relation queries.

The Solution: Changed Collection to true to always allow count operations in select clauses, regardless of whether the query returns a single item or collection.

Code Quality Assessment

✅ Strengths:

• Minimal, targeted fix: Changes only the necessary line without over-engineering
• Correct logic: Hardcoding AllowCount to true makes sense because count operations should be available even on single-item queries when selecting nested relations
• Excellent test coverage: The new tests comprehensively cover the typing scenarios that were broken
• Clear intent: The test comments clearly explain when _count should and shouldn't be allowed

✅ TypeScript Safety:

• The fix properly enables _count typing for to-one relations without breaking existing functionality
• Test includes appropriate @ts-expect-error annotations for cases where _count should not be allowed
• No risk of runtime errors since this is purely a typing fix

✅ Test Quality:

• Tests cover both positive cases (where _count should work) and negative cases (where it shouldn't)
• Tests verify the TypeScript compiler behavior directly, which is exactly what this fix addresses
• Consistent with existing test patterns in the file

Potential Concerns

⚠️ Minor observations:

1. The change affects all FindArgs usage, not just to-one relations, but this appears intentional and correct
2. No documentation updates needed since this fixes existing functionality rather than adding new features

Performance Considerations

• No performance impact: This is a compile-time typing fix with no runtime changes
• No breaking changes: Existing code will continue to work exactly the same way

Security Assessment

• No security implications: Type-only change with no runtime behavior modification

Recommendation

✅ APPROVE - This is a well-executed fix that:

• Correctly addresses the reported issue with minimal changes
• Includes comprehensive test coverage
• Follows established coding patterns
• Has no negative side effects or breaking changes

The fix properly enables _count in select clauses for to-one relations while maintaining type safety for cases where it shouldn't be allowed.

[coderabbitai]

📝 Walkthrough

Walkthrough

The PR updates the FindArgs type definition to hard-code the include/select-omit behavior as always enabled, and adds TypeScript type-checking expectations for _count usage across various relation selection scenarios in findMany operations.

Changes

Cohort / File(s)	Summary
Type Definition Fix packages/orm/src/client/crud-types.ts	Updated FindArgs type to parameterize SelectIncludeOmit with true instead of Collection, ensuring consistent include/select-omit behavior regardless of collection context.
Type-Checking Tests tests/e2e/orm/client-api/find.test.ts	Added TypeScript expectations for _count usage in findMany operations: allows _count on to-many relations (posts via user, posts via author on post), and verifies rejection of _count on non-relation fields (comment).

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Poem

🐰 A hop, skip, and jump through the type maze,
FindArgs now shines in a clearer blaze!
The _count hops freely on relations galore,
While tests guard the path forevermore. 🎉

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly describes the specific fix: addressing _count typing in select clauses for to-one relation queries. It accurately reflects the core change in FindArgs type parameterization.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

• 📝 Generate docstrings (stacked PR)
• 📝 Generate docstrings (commit on current branch)

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/issue-2343

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

🧹 Nitpick comments (1)

tests/e2e/orm/client-api/find.test.ts (1)

1140-1143: Use _count: true instead of _count: {} for a precise guard test.

{} is unconditionally invalid for SelectCount (boolean | { select: {...} }), so the @ts-expect-error here would never become stale — even if Comment later gains a to-many relation, the error would persist for the wrong reason, masking a HasToManyRelations guard regression. _count: true is valid exactly when _count is present in the type, which is the right sentinel.

The existing analogous test on line 1021 already uses _count: true; this should match that pattern. Also consider adding an inline description to the @ts-expect-error comment for consistency with line 1020.

♻️ Proposed fix

         client.comment.findMany({
-            // `@ts-expect-error`
-            select: { _count: {} },
+            // `@ts-expect-error` Comment has no to-many relations to count
+            select: { _count: true },
         });

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/e2e/orm/client-api/find.test.ts` around lines 1140 - 1143, The test
uses an invalid sentinel select `{ _count: {} }` which will always be a type
error; update the call to client.comment.findMany to use `_count: true` instead
(so the `@ts-expect-error` detects presence/absence of _count correctly) and add
an inline description to the `@ts-expect-error` comment (matching the style on
line 1020) to clarify the expected guard (refer to client.comment.findMany,
SelectCount, Comment and HasToManyRelations in the test).

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@tests/e2e/orm/client-api/find.test.ts`:
- Around line 1140-1143: The test uses an invalid sentinel select `{ _count: {}
}` which will always be a type error; update the call to client.comment.findMany
to use `_count: true` instead (so the `@ts-expect-error` detects
presence/absence of _count correctly) and add an inline description to the
`@ts-expect-error` comment (matching the style on line 1020) to clarify the
expected guard (refer to client.comment.findMany, SelectCount, Comment and
HasToManyRelations in the test).

---

ℹ️ Review info

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 89e3acb and 8292902.

📒 Files selected for processing (2)

• packages/orm/src/client/crud-types.ts
• tests/e2e/orm/client-api/find.test.ts