fix(core): coerce calendarDay writes to Date before Prisma 7 validation by borisno2 · Pull Request #637 · OpenSaasAU/stack

borisno2 · 2026-07-10T07:56:14Z

Summary

calendarDay() gained a field-level resolveInput hook that converts a valid YYYY-MM-DD string to a UTC-midnight Date before the write reaches Prisma. Prisma 7's client validator rejects a bare date string for a DateTime @db.Date column, so the documented string-write path was 500ing (calendarDay write to Prisma 7 @db.Date still 500s: #602 added the string type + read normaliser but no write-side string→Date coercion (#571 regression) #621, a regression from Release: Validation & field-type input parity (zod 4.4 + calendarDay) — PRD #582 #602).
The hook reads resolvedData[fieldKey] (not raw inputData), so a list-level resolveInput that injects a default for an omitted key still gets coerced instead of being overwritten with null.
Malformed strings, null/undefined, and already-Date values pass through the hook unchanged so existing validation (isRequired, format errors) is unaffected.
Widened the field's zod schema to z.union([stringSchema, z.date()]) since a successful write now reaches validation as a Date (resolveInput runs before validation in the write pipeline).
Reads are unchanged — resolveOutput still normalises back to a YYYY-MM-DD string.

Test plan

Unit tests for the resolveInput hook (string→Date coercion, pass-through cases, reading resolvedData vs inputData)
Unit tests for the widened zod schema (string, Date, malformed string)
End-to-end tests via context.db.event.create/update against a mocked Prisma client asserting the value forwarded to Prisma is a Date, reproducing the issue's repro scenario
pnpm test (packages/core) — 752 passed
pnpm lint, pnpm manypkg fix, pnpm format
tsc --noEmit

Closes #621

… 7 validation Prisma 7's client validator rejects a bare YYYY-MM-DD string for a DateTime @db.Date column. Add a resolveInput hook that converts a valid string to a UTC-midnight Date before the write reaches Prisma, and widen the field's zod schema to accept either shape (resolveInput runs before validation in the write pipeline). Closes #621

vercel · 2026-07-10T07:56:19Z

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
stack-docs	Ready	Preview, Comment	Jul 10, 2026 7:57am

changeset-bot · 2026-07-10T07:56:22Z

🦋 Changeset detected

Latest commit: f38867e

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 9 packages

Name	Type
@opensaas/stack-core	Patch
@opensaas/stack-auth	Patch
@opensaas/stack-cli	Patch
@opensaas/stack-rag	Patch
@opensaas/stack-storage	Patch
@opensaas/stack-tiptap	Patch
@opensaas/stack-ui	Patch
@opensaas/stack-storage-s3	Patch
@opensaas/stack-storage-vercel	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

borisno2 · 2026-07-10T07:57:30Z

Review

Overview

Fixes #621: calendarDay writes were 500ing on Prisma 7 because the documented YYYY-MM-DD string write path reached the client's @db.Date validator unconverted. This PR adds a field-level resolveInput hook that coerces a valid YYYY-MM-DD string to a UTC-midnight Date before the write pipeline's validation phase, and widens calendarDay's zod schema to z.union([stringSchema, z.date()]) to accept the post-coercion shape.

Correctness

Hook ordering is right: hook-pipeline.ts runs field resolveInput (phase 1.5) strictly before validateFieldRules/zod (phase 3), so a valid string is a Date by the time the schema checks it. Confirmed by tracing context/hook-pipeline.ts.
Reads resolvedData[fieldKey] rather than inputData, so a list-level resolveInput that injects a default for an omitted key is honored (loop in executeFieldResolveInputHooks only runs for keys present in resolvedData, which already reflects that injected default). Matches the issue's explicit ask and is covered by a test.
UTC midnight construction (${value}T00:00:00.000Z) avoids the day-drift footgun the read-side formatCalendarDay already guards against.
Malformed strings, null/undefined, and existing Date instances pass through the hook unchanged, so isRequired and format-error behavior is preserved.

Minor observation (non-blocking)

For a value that's neither a valid YYYY-MM-DD string nor a Date (e.g. a stray number/object reaching context.db from an untyped JS caller), the error message quality regresses slightly. Previously the schema was a plain z.string() with a custom "must be a valid date in ISO8601 format" message; now z.union([stringSchema, z.date()]) surfaces zod's generic "Invalid input" top-level message instead for non-string/non-date values (verified locally — a number input flips from the custom message to "Invalid input"). This is an edge case (the field's TS type is string, so a typed caller can't reach it), and it's not covered by a test either before or after this change, so it's not a regression this PR needs to fix — just worth a follow-up if better DX for that edge case matters.

Test coverage

Strong — new tests cover the resolveInput hook directly (string→Date, Date/null/undefined pass-through, malformed-string pass-through, resolvedData vs inputData), the widened zod schema, and — notably — an end-to-end repro via context.db.event.create/update against a mocked Prisma client that asserts the exact value forwarded to the client is a Date, which is the most direct verification of the original bug. Read-side normalization back to YYYY-MM-DD is also re-verified end-to-end.

Style / conventions

Follows the existing field-self-containment pattern (no switch statements added elsewhere).
Comments explain the non-obvious "why" (hook ordering constraint, UTC-midnight rationale) rather than restating code.
Changeset present and correctly scoped as patch.

Risk

Low. Change is scoped to a single field builder, additive to the hook object (still overridable by user-provided hooks per the existing merge pattern), and read behavior is untouched. All 752 core tests + typecheck + lint pass.

No blocking issues found.

Generated by Claude Code

github-actions · 2026-07-10T08:08:23Z