Rotorsoft / act-root / 32881014490

100%

push

github

fix(act): let the schema decide which fields are dates (#1570)

* fix(act): let the schema decide which fields are dates

JSON has no date type, so a Date is stored as its ISO form and something has
to turn it back. Adapters did it by SHAPE — a regex against every string in
every event — because an adapter has never seen the event's Zod schema. That
revived any ISO-8601-looking value, including fields declared z.string(): an
upstream API's created_at came back a Date, so a cold read produced state that
failed its own schema while a warm read did not.

The schema is the authority and the framework holds it. Each event's z.date()
paths are resolved once at act().build() and exactly those are converted on
read. z.date() round-trips as a Date everywhere; an ISO-shaped z.string()
stays a string.

Resolved in ONE pass over the declared schema, alongside the sensitive-field
markers that pass already computed — walking twice for two answers would be
the same work done twice.

Applied at every seam an event reaches user code: the fold (composed onto
state.view, so it stacks with the PII gate), snapshots (whose data is folded
STATE, so their dates come from the state schema — without this a restart
would lose every z.date() the state holds), query, query_array, per-event
reaction handlers, and batch handlers.

Adapters stop guessing: the pg pool JSONB parser, sqlite's parse_json, both
decrypt paths and CsvFile all return what they stored. The store TCK's date
case now asserts LOSSLESS RECOVERY rather than a runtime type, since a
serializing adapter hands back the ISO form and InMemory (which holds
references) hands back the Date — both correct at that layer.

Faster as a side effect. Isolated parse: 7.7x floor -> 1.0x for an event with
no dates, 80-87% cheaper across the shapes measured. End to end on Postgres,
cold load 0.600ms -> 0.536ms (~11%); commit unchanged, since the reviver only
ever ran on read. Both tables in act-pg/PERFORMANCE.md.

dateReviver stays... (continued)

4282 of 4282 branches covered (100.0%)

Branch coverage included in aggregate %.

118 of 118 new or added lines in 6 files covered. (100.0%)

9251 of 9251 relevant lines covered (100.0%)

1167.99 hits per line