fix: use z.strictObject consistently

[ymc9]

No description provided.

[coderabbitai]

Note

Other AI code review bot(s) detected

CodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review.

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

✨ Finishing Touches

🧪 Generate unit tests

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/validation-strict-schema

---

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

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

CodeRabbit Commands (Invoked using PR/Issue comments)

Type @coderabbitai help to get the list of available commands.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

Status, Documentation and Community

• Visit our Status Page to check the current availability of CodeRabbit.
• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[claude]

Claude finished @ymc9's task —— View job

---

PR Review: Fix z.strictObject consistency

Todo List:

• Read and analyze changed files
• Evaluate code quality and best practices
• Check for potential bugs or issues
• Assess performance considerations
• Review security implications
• Evaluate test coverage needs
• Provide comprehensive feedback

---

Review Summary

This PR standardizes the use of z.strictObject() instead of z.object() across the codebase, which is a good practice for input validation. The changes are focused and consistent.

✅ Positive Aspects

Code Quality & Best Practices:

• ✅ Consistent API: Standardizing on z.strictObject() provides better validation by rejecting unknown properties
• ✅ Security Enhancement: Strict validation prevents potential issues from unexpected properties
• ✅ Clean Refactoring: The changes in makeRelationSelectIncludeSchema() improve code structure by extracting schema refinements

Performance:

• ✅ No Performance Impact: The change from z.object() to z.strictObject() has minimal performance difference
• ✅ Better Error Handling: Strict validation can fail faster on invalid input

🔍 Areas of Interest

Schema Validation Changes:

1. packages/runtime/src/client/crud/validator.ts: Multiple z.object() → z.strictObject() conversions:

   • Line 747: makeCreateSchema()
   • Line 1009: makeUpdateSchema()
   • Line 1020: makeUpdateManySchema()
   • Line 1037: makeUpsertSchema()
   • Line 1149: makeDeleteSchema()
   • Line 1188: makeCountAggregateInputSchema()
   • Line 1258: makeGroupBySchema()

2. packages/zod/src/index.ts:

   • Line 10: makeSelectSchema() function

Code Structure Improvements:

• The refactoring in makeRelationSelectIncludeSchema() (lines 630-656) improves maintainability by applying refinements after schema creation

🤔 Potential Considerations

Breaking Changes:

• ⚠️ Stricter Validation: This change makes validation more strict, which could potentially break existing code that passes extra properties
• 📝 Recommendation: Ensure this change is documented in release notes as it could affect client code

Migration Path:

• 💡 Consider: Adding unit tests that verify strict validation behavior
• 💡 Consider: Testing with real-world schemas to ensure no regressions

🧪 Test Coverage Recommendations

1. Add tests verifying that schemas reject unknown properties:

   // Example test case
   expect(() => schema.parse({ validField: 'value', unknownField: 'should fail' }))
     .toThrow();

2. Regression tests for all modified schema creation functions

3. Integration tests ensuring existing functionality still works

🔒 Security Assessment

✅ Security Positive: Using z.strictObject() improves security by:

• Preventing property pollution attacks
• Ensuring only expected properties are processed
• Making validation behavior more predictable

📊 Overall Assessment

This is a well-executed refactoring that improves code consistency and security. The changes are:

• ✅ Systematic and thorough
• ✅ Low risk (pure refactoring)
• ✅ Security positive
• ⚠️ Potentially breaking (stricter validation)

🎯 Recommendations

1. Document the breaking change in release notes
2. Add comprehensive tests for strict validation behavior
3. Consider gradual rollout if this affects many existing users
4. Verify E2E tests pass with the stricter validation

The PR title and approach are excellent - this type of consistency improvement strengthens the codebase's validation layer.

---

[Copilot]

Pull Request Overview

This pull request standardizes the use of z.strictObject instead of z.object throughout the codebase to ensure consistent strict object validation behavior. The change enforces that objects cannot have additional properties beyond those defined in the schema.

Key Changes

• Replace z.object with z.strictObject across multiple schema definitions
• Refactor some schema building patterns to use extend() instead of merge() with strict objects
• Extract object schema creation in makeRelationSelectIncludeSchema to allow for refinement application

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
packages/zod/src/index.ts	Updates makeSelectSchema to use z.strictObject
packages/runtime/src/client/crud/validator.ts	Comprehensive replacement of z.object with z.strictObject across CRUD operation schemas

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
You can also share your feedback on Copilot code review for a chance to win a $100 gift card. Take the survey.}

[claude]

Claude finished @ymc9's task —— View job

---

Claude finished @ymc9's task —— View job

---

PR Review: Fix z.strictObject consistency

Todo List:

• Read and analyze changed files
• Evaluate code quality and best practices
• Check for potential bugs or issues
• Assess performance considerations
• Review security implications
• Evaluate test coverage needs
• Provide comprehensive feedback

---

Review Summary

This PR standardizes the use of z.strictObject() instead of z.object() across the codebase, which is a good practice for input validation. The changes are focused and consistent.

✅ Positive Aspects

Code Quality & Best Practices:

• ✅ Consistent API: Standardizing on z.strictObject() provides better validation by rejecting unknown properties
• ✅ Security Enhancement: Strict validation prevents potential issues from unexpected properties
• ✅ Clean Refactoring: The changes in makeRelationSelectIncludeSchema() improve code structure by extracting schema refinements

Performance:

• ✅ No Performance Impact: The change from z.object() to z.strictObject() has minimal performance difference
• ✅ Better Error Handling: Strict validation can fail faster on invalid input

🔍 Areas of Interest

Schema Validation Changes:

1. packages/runtime/src/client/crud/validator.ts: Multiple z.object() → z.strictObject() conversions:

   • Line 747: makeCreateSchema()
   • Line 1009: makeUpdateSchema()
   • Line 1020: makeUpdateManySchema()
   • Line 1037: makeUpsertSchema()
   • Line 1149: makeDeleteSchema()
   • Line 1188: makeCountAggregateInputSchema()
   • Line 1258: makeGroupBySchema()

2. packages/zod/src/index.ts:

   • Line 10: makeSelectSchema() function

Code Structure Improvements:

• The refactoring in makeRelationSelectIncludeSchema() (lines 630-656) improves maintainability by applying refinements after schema creation

🤔 Potential Considerations

Breaking Changes:

• ⚠️ Stricter Validation: This change makes validation more strict, which could potentially break existing code that passes extra properties
• 📝 Recommendation: Ensure this change is documented in release notes as it could affect client code

Migration Path:

• 💡 Consider: Adding unit tests that verify strict validation behavior
• 💡 Consider: Testing with real-world schemas to ensure no regressions

🧪 Test Coverage Recommendations

1. Add tests verifying that schemas reject unknown properties:

   // Example test case
   expect(() => schema.parse({ validField: 'value', unknownField: 'should fail' }))
     .toThrow();

2. Regression tests for all modified schema creation functions

3. Integration tests ensuring existing functionality still works

🔒 Security Assessment

✅ Security Positive: Using z.strictObject() improves security by:

• Preventing property pollution attacks
• Ensuring only expected properties are processed
• Making validation behavior more predictable

📊 Overall Assessment

This is a well-executed refactoring that improves code consistency and security. The changes are:

• ✅ Systematic and thorough
• ✅ Low risk (pure refactoring)
• ✅ Security positive
• ⚠️ Potentially breaking (stricter validation)

🎯 Recommendations

1. Document the breaking change in release notes
2. Add comprehensive tests for strict validation behavior
3. Consider gradual rollout if this affects many existing users
4. Verify E2E tests pass with the stricter validation

The PR title and approach are excellent - this type of consistency improvement strengthens the codebase's validation layer.

---