Rotorsoft / act-root / 33339147622

100%

push

github

fix(act): revive dates on read instead of re-validating the payload (#1601)

* fix(act): revive dates on read instead of re-validating the payload

Reading an event ran a throwing z.parse() over its data whenever the
schema mentioned a date. All that is needed there is to turn stored ISO
strings back into Dates — the payload was already validated on write —
and the extra validation rejected payloads the framework itself wrote.

A sensitive() field is moved into the pii sidecar on write, so data
structurally cannot hold it, and a schema that requires it fails. That
made an aggregate carrying both a sensitive field and a date unreadable
and unwritable: query, load, and every later command threw.

Three changes. The sensitive keys are optional in the rebuilt schema,
since they are never in data. Reviving is a safeParse that falls back to
the stored value, so a payload written against an older declaration
still reads. The sidecar gets its half of the same rebuild, so a
disclosed sensitive(z.date()) is a Date rather than a string beside a
plain sibling that is one.

The rebuild also descends through default, prefault, catch, readonly,
nonoptional and tuple, which previously left a date inside them unrevived.

Cost is unchanged (0.0%, -2.7%, -0.5% across a one-date, a nested and an
array payload): safeParse costs what parse did, and only the sensitive
keys gained a wrapper. Reviving the sidecar runs only when one is
present.

Closes #1594

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014Vfpx1bDy3t57oHBynvNPF

* fix(act): leave the sensitive keys out of the read schema entirely

They were optional, which says they might be there. They are not: the
write path moves them into the pii sidecar, so data does not hold them
and there is nothing to describe. Anything that does turn up under one
of those names rides through the loose object untouched.

Also 3.8% cheaper on an event with three sensit... (continued)

4332 of 4332 branches covered (100.0%)

Branch coverage included in aggregate %.

64 of 64 new or added lines in 3 files covered. (100.0%)

9294 of 9294 relevant lines covered (100.0%)

1177.72 hits per line