Skip to content

Format generated now/now_on_write values to the field's declared type - #3

Open
chrisstrahl wants to merge 1 commit into
callumalpass:mainfrom
chrisstrahl:fix/generated-now-date-fields
Open

Format generated now/now_on_write values to the field's declared type#3
chrisstrahl wants to merge 1 commit into
callumalpass:mainfrom
chrisstrahl:fix/generated-now-date-fields

Conversation

@chrisstrahl

Copy link
Copy Markdown

Bug

Any field that pairs a date type with a generated timestamp makes create() and update() fail their own validation:

updated:
  type: date
  generated: now_on_write

generateValue() (and the inline now_on_write stamping in update()) always emit new Date().toISOString() — a full ISO datetime — regardless of the field's declared type. The operation stamps 2026-07-23T06:09:41.123Z into a date field, then validation rejects the value it just generated with invalid_date, and the whole write fails with validation_failed.

validate() passes on the same files because the on-disk values are proper YYYY-MM-DD dates; the invalid value is introduced by the write path itself. So collections in this shape validate clean but can never be written through the API — every update fails even when the requested field change is a no-op.

Repro (v0.2 profile, default_validation: error): declare the field above, create a file with a valid date value, then call collection.update({path, fields: {title: "x"}})validation_failed / invalid_date on updated.

Fix

  • generateValue() formats now / now_on_write to the declared field type: dateYYYY-MM-DD, timeHH:MM:SS, anything else → full ISO datetime (all UTC, consistent with the existing {today: true} lifecycle provider and the validator's UTC-based Date coercion).
  • The inline now_on_write stamping in update() now goes through the same helper instead of a hardcoded toISOString().
  • The v0.2→v0.3 type migration maps now / now_on_write on date-typed fields to the {today: true} provider instead of {now: true}, so migrated collections don't inherit the same failure.

Tests

New test/generated-date-fields.test.ts covers create, update, and migration for date/datetime/time-typed generated fields (all three failed before the fix). Full suite: 2005 passed; the one failing test (v03-conformance lifecycle conflict diagnostic) fails identically on a clean checkout of main and is unrelated.

Found in production use: a knowledge-base collection where every type declares updated: {type: date, generated: now_on_write}mdbase update was unusable across the entire collection.

🤖 Generated with Claude Code

Generated now/now_on_write values were always stamped as a full ISO
datetime, regardless of the field's declared type. A field like

  updated:
    type: date
    generated: now_on_write

made every create() and update() fail its own validation with
invalid_date: the operation stamped an ISO datetime into a date field
and then rejected the value it had just generated. validate() passed
on the same files because the on-disk values were proper YYYY-MM-DD
dates — the invalid value was introduced by the write path itself.

Fix: generateValue() and the inline now_on_write stamping in update()
now format the timestamp to the declared field type (date → YYYY-MM-DD,
time → HH:MM:SS, otherwise full ISO datetime, all UTC — consistent with
the existing {today: true} lifecycle provider and Date coercion). The
v0.2→v0.3 type migration likewise maps now/now_on_write on date-typed
fields to the {today: true} provider instead of {now: true}, so
migrated collections don't inherit the same failure.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant