Conversation
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✅ Files skipped from review due to trivial changes (1)
📝 WalkthroughWalkthroughVersion bumps from 3.6.0 → 3.6.1 across package manifests; CLI gains a Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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. Comment |
Contributor
|
Claude finished @ymc9's task —— View job Pull Request ReviewReviewing this dev to main merge (v3.6.1) for code quality, potential issues, performance, security, and test coverage. Review Tasks:
Review SummaryThis PR merges dev to main for version 3.6.1, containing several important bug fixes and improvements across the CLI, ORM, and VSCode extension components. 🔍 Key Changes Analyzed1. CLI Enhancements (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
package.json (1)
17-17: Pin pnpm to the repository-required version.The root manifest currently pins
pnpm@10.33.0, but the review guideline requirespnpm@10.12.1.Proposed fix
- "packageManager": "pnpm@10.33.0", + "packageManager": "pnpm@10.12.1",As per coding guidelines,
Use pnpm for package management with version pinned to pnpm@10.12.1.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@package.json` at line 17, Update the repository's package manager pin by changing the package.json "packageManager" field from "pnpm@10.33.0" to "pnpm@10.12.1"; locate the "packageManager" entry in package.json and replace the version string so the manifest pins pnpm@10.12.1 as required by the guidelines.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@packages/orm/src/client/crud/dialects/postgresql.ts`:
- Around line 110-115: The DATE scalar and array handling is incomplete:
register the DATE array OID (1182) with the same guarded parser logic used for
TIMESTAMP arrays by calling pg.types.setTypeParser for the DATE array OID and
using parsePostgresArray with an element parser that constructs a Date from the
element and falls back to the raw element when isNaN(date.getTime()); also
update the existing scalar pg.types.setTypeParser(pg.types.builtins.DATE, ...)
to include the same NaN fallback (return the original raw value when new
Date(...) yields an invalid date) so DATE and DATE[] match TIMESTAMP/TIMESTAMP[]
behavior (refer to pg.types.setTypeParser, parsePostgresArray, and
pg.types.builtins.DATE / array OID 1182).
In `@tests/e2e/orm/client-api/pg-date-field.test.ts`:
- Around line 95-96: The test's failing assertion is a false positive because
createSchema.safeParse({ data: { name: 'Conference', createdAt: '2007-05-23' }
}) is invalid due to a missing required eventDate, not necessarily createdAt;
update the test so the parsed payload includes eventDate and uses an actually
invalid createdAt (or assert the plain-date acceptance explicitly).
Specifically, modify the data passed to createSchema.safeParse (the object
referenced by invalidCreateResult) to include eventDate with a valid value and
change createdAt to an intentionally invalid value (e.g., a malformed date
string) or alternatively assert that a plain ISO date string for createdAt is
accepted by calling createSchema.safeParse with both eventDate and createdAt
valid and checking success is true. Ensure you update the expectation for
invalidCreateResult.success accordingly.
- Around line 101-102: Replace non-standard date literals using a colon
separator with ISO 8601 T-separated timestamps in the test assertions: update
the expectations in pg-date-field.test.ts that reference created.eventDate and
created.createdAt (and the similar assertions later around lines referencing the
same checks) to use "2007-05-23T00:00:00.000Z" instead of
"2007-05-23:00:00:00.000Z" so the Date parsing is explicit and
standard-compliant.
---
Nitpick comments:
In `@package.json`:
- Line 17: Update the repository's package manager pin by changing the
package.json "packageManager" field from "pnpm@10.33.0" to "pnpm@10.12.1";
locate the "packageManager" entry in package.json and replace the version string
so the manifest pins pnpm@10.12.1 as required by the guidelines.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 371ef7dd-194b-4e0d-b7e4-a4f44239b8df
📒 Files selected for processing (35)
package.jsonpackages/auth-adapters/better-auth/package.jsonpackages/cli/package.jsonpackages/cli/src/actions/action-utils.tspackages/cli/src/actions/db.tspackages/cli/src/actions/migrate.tspackages/cli/src/index.tspackages/cli/test/action-utils.test.tspackages/clients/client-helpers/package.jsonpackages/clients/tanstack-query/package.jsonpackages/common-helpers/package.jsonpackages/config/eslint-config/package.jsonpackages/config/tsdown-config/package.jsonpackages/config/typescript-config/package.jsonpackages/config/vitest-config/package.jsonpackages/create-zenstack/package.jsonpackages/ide/vscode/package.jsonpackages/ide/vscode/src/extension/main.tspackages/language/package.jsonpackages/orm/package.jsonpackages/orm/src/client/crud/dialects/postgresql.tspackages/orm/src/client/zod/factory.tspackages/plugins/policy/package.jsonpackages/schema/package.jsonpackages/sdk/package.jsonpackages/server/package.jsonpackages/server/test/openapi/baseline/rpc.baseline.yamlpackages/testtools/package.jsonpackages/zod/package.jsonsamples/orm/package.jsontests/e2e/orm/client-api/pg-date-field.test.tstests/e2e/package.jsontests/regression/package.jsontests/runtimes/bun/package.jsontests/runtimes/edge-runtime/package.json
Comment on lines
+110
to
+115
| // date | ||
| pg.types.setTypeParser( | ||
| pg.types.builtins.DATE, | ||
| // append time and UTC offset to force a valid UTC date time | ||
| (v) => new Date(`${v}T00:00:00Z`), | ||
| ); |
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Inspect PostgreSQL type parser registrations around DATE/TIMESTAMP arrays.
# Expect: TIMESTAMP array OID 1115 and DATE array OID 1182 should both be registered if DATE arrays are supported.
rg -n -C3 'setTypeParser\(|builtins\.DATE|builtins\.TIMESTAMP|\b1115\b|\b1182\b' packages/orm/src/client/crud/dialects/postgresql.ts
rg -n -C3 '@db\.Date.*\[\]|\[\].*@db\.Date' .Repository: zenstackhq/zenstack
Length of output: 1548
🏁 Script executed:
#!/bin/bash
# Check the full context around the DATE parser, including function scope and imports
head -120 packages/orm/src/client/crud/dialects/postgresql.ts | tail -40Repository: zenstackhq/zenstack
Length of output: 1810
🏁 Script executed:
#!/bin/bash
# Search for parsePostgresArray function to verify it's in scope
rg -n 'parsePostgresArray|const parsePostgresArray|function parsePostgresArray' packages/orm/src/client/crud/dialects/postgresql.tsRepository: zenstackhq/zenstack
Length of output: 252
🏁 Script executed:
#!/bin/bash
# Search for actual usage of DateTime[] types with `@db.Date` in schema files
rg -n 'DateTime\[\]' packages/ tests/ | head -20
rg -n '@db\.Date' packages/ tests/ | head -20Repository: zenstackhq/zenstack
Length of output: 2663
🏁 Script executed:
#!/bin/bash
# Check PostgreSQL type OID mappings - verify 1182 is DATE array
rg -n '1182|builtins\.DATE' packages/orm/src/client/crud/dialects/postgresql.tsRepository: zenstackhq/zenstack
Length of output: 114
🏁 Script executed:
#!/bin/bash
# Search for any schema files that might combine DateTime[] with `@db.Date`
find packages tests -name "*.zmodel" -o -name "*schema*.ts" | xargs rg -l "DateTime\[.*@db.Date|@db.Date.*DateTime\[" 2>/dev/null | head -10Repository: zenstackhq/zenstack
Length of output: 45
🏁 Script executed:
#!/bin/bash
# Check schema test files specifically for DateTime[] combined with `@db.Date`
rg -B2 -A2 'DateTime\[\]' tests/e2e/orm/client-api/pg-date-field.test.tsRepository: zenstackhq/zenstack
Length of output: 45
🏁 Script executed:
#!/bin/bash
# Verify OID 1182 is correct and check if there are any other DATE-related OID registrations
rg -n 'DATE|1182|builtins' packages/orm/src/client/crud/dialects/postgresql.ts | head -20Repository: zenstackhq/zenstack
Length of output: 203
🏁 Script executed:
#!/bin/bash
# Check if there are test cases for DateTime array fields at all
rg -n 'DateTime\[\]' tests/e2e/orm/client-api/ -A5 -B5 | head -40Repository: zenstackhq/zenstack
Length of output: 953
🏁 Script executed:
#!/bin/bash
# Check Prisma field type compatibility - does `@db.Date` work with arrays?
rg -n 'DateTime\[\]' packages/schema tests/ -B5 -A5 | head -50Repository: zenstackhq/zenstack
Length of output: 953
🏁 Script executed:
#!/bin/bash
# Check if there's any schema validation or documentation about `@db.Date` with arrays
rg -n '@db\.Date' packages/language res/ -B2 -A2Repository: zenstackhq/zenstack
Length of output: 887
🏁 Script executed:
#!/bin/bash
# Verify the actual Prisma/Zenstack schema definition for `@db.Date` attribute
rg -n 'db\.Date|DateTimeField' packages/language/res/stdlib.zmodel -B3 -A3Repository: zenstackhq/zenstack
Length of output: 1024
🏁 Script executed:
#!/bin/bash
# Check if TYPE_PARSER or type registration has any comments about array support
rg -n 'TYPE_PARSER|dateParserMap|parseDate' packages/orm/src/client/crud/dialects/postgresql.ts -B2 -A2Repository: zenstackhq/zenstack
Length of output: 45
🏁 Script executed:
#!/bin/bash
# Check if Prisma/Zenstack schema allows `@db.Date` on array fields
rg -n 'DateTime\[\].*@db\.' packages/schema tests/ -iRepository: zenstackhq/zenstack
Length of output: 45
🏁 Script executed:
#!/bin/bash
# Look at how the `@db.Date` attribute constraint works in stdlib
cat packages/language/res/stdlib.zmodel | grep -A5 -B5 "@db.Date"Repository: zenstackhq/zenstack
Length of output: 617
🏁 Script executed:
#!/bin/bash
# Check actual test schema definitions with `@db.Date` to see if arrays are combined
rg -B5 -A5 '@db\.Date' tests/e2e/orm/client-api/pg-date-field.test.tsRepository: zenstackhq/zenstack
Length of output: 4272
🏁 Script executed:
#!/bin/bash
# Inspect if there are runtime type parser registrations for other array types beyond TIMESTAMP
rg -n 'setTypeParser.*1[0-9]{3}' packages/orm/src/client/crud/dialects/postgresql.tsRepository: zenstackhq/zenstack
Length of output: 127
🏁 Script executed:
#!/bin/bash
# Check if Prisma allows `@db.Date` on DateTime[] fields - look for any validation or comments
rg -n 'DateTime\[\]|array.*@db|@db.*array' packages/ -i -B2 -A2 | head -30Repository: zenstackhq/zenstack
Length of output: 45
🏁 Script executed:
#!/bin/bash
# Search for any schema compilation or validation that might restrict `@db.Date` to non-arrays
rg -n 'DateTimeField|targetField' packages/schema packages/language/src -B2 -A2 | head -40Repository: zenstackhq/zenstack
Length of output: 2472
🏁 Script executed:
#!/bin/bash
# Check if there's actual production usage or tests that combine DateTime[] with any `@db` modifier
find tests -name "*.test.ts" -exec grep -l "DateTime\[\]" {} \; | xargs grep -l "@db\." | head -5Repository: zenstackhq/zenstack
Length of output: 45
🏁 Script executed:
#!/bin/bash
# Check attribute validator logic - does it explicitly reject arrays for `@db.Date`?
cat packages/language/src/validators/attribute-application-validator.ts | grep -A20 "DateTimeField"Repository: zenstackhq/zenstack
Length of output: 930
🏁 Script executed:
#!/bin/bash
# Verify if isArray field type check exists in the validator
rg -n 'isArray|\.isArray|\[\]' packages/language/src/validators/attribute-application-validator.ts | head -20Repository: zenstackhq/zenstack
Length of output: 396
🏁 Script executed:
#!/bin/bash
# Check if there's a comment or issue about DateTime[] arrays needing `@db` modifiers
rg -n 'DateTime.*\[\].*@db|array.*modifier|array.*attribute' packages/ -i | grep -v node_modules | head -20Repository: zenstackhq/zenstack
Length of output: 2564
🏁 Script executed:
#!/bin/bash
# Look at the full targetField validation function to understand array handling
sed -n '549,600p' packages/language/src/validators/attribute-application-validator.tsRepository: zenstackhq/zenstack
Length of output: 2131
Register DATE[] (OID 1182) with the same guarded parser as TIMESTAMP[].
Line 112 only registers scalar DATE. Since TIMESTAMP arrays are handled explicitly at line 98 with parsePostgresArray, DATE[] should receive the same treatment for consistency. The DATE scalar parser also lacks the NaN fallback check present in the TIMESTAMP parser, which means invalid dates return "Invalid Date" instead of the original raw value.
Suggested patch
+ const parseDate = (v: unknown) => {
+ if (typeof v !== 'string') {
+ return v;
+ }
+ const result = new Date(`${v}T00:00:00Z`);
+ return Number.isNaN(result.getTime()) ? v : result;
+ };
+
// date
- pg.types.setTypeParser(
- pg.types.builtins.DATE,
- // append time and UTC offset to force a valid UTC date time
- (v) => new Date(`${v}T00:00:00Z`),
- );
+ pg.types.setTypeParser(pg.types.builtins.DATE, parseDate);
+ // date array
+ pg.types.setTypeParser(1182, (value) => {
+ if (typeof value !== 'string') {
+ return value;
+ }
+ try {
+ return parsePostgresArray(value).map(parseDate);
+ } catch {
+ return value;
+ }
+ });🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@packages/orm/src/client/crud/dialects/postgresql.ts` around lines 110 - 115,
The DATE scalar and array handling is incomplete: register the DATE array OID
(1182) with the same guarded parser logic used for TIMESTAMP arrays by calling
pg.types.setTypeParser for the DATE array OID and using parsePostgresArray with
an element parser that constructs a Date from the element and falls back to the
raw element when isNaN(date.getTime()); also update the existing scalar
pg.types.setTypeParser(pg.types.builtins.DATE, ...) to include the same NaN
fallback (return the original raw value when new Date(...) yields an invalid
date) so DATE and DATE[] match TIMESTAMP/TIMESTAMP[] behavior (refer to
pg.types.setTypeParser, parsePostgresArray, and pg.types.builtins.DATE / array
OID 1182).
Contributor
|
Claude finished @ymc9's task —— View job Pull Request ReviewReviewing this dev to main merge (v3.6.1) for code quality, potential issues, performance, security, and test coverage. Review Tasks:
Review SummaryThis PR merges dev to main for version 3.6.1, containing several important bug fixes and improvements across the CLI, ORM, and VSCode extension components. 🔍 Key Changes Analyzed1. CLI Enhancements (
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary by CodeRabbit
New Features
Enhancements
Tests
Chores
Bug Fixes