fix(acceptance): type-correct valid samples & negatives (date fields → real dates; type beats name) - #212
Merged
Merged
Conversation
…idValue)
Live deep-chain build (Organization→Project→Task) parked Task: fast gate green but
e2e acceptance timed out with the task-form never hiding — i.e. the create was
failing, not a transient hiccup as the build's own note guessed.
Root cause: validValue (acceptance-spec.ts) had no case for date/datetime/timestamp
types, so a dueDate field got the generic '${name}-${seed}' sample ('dueDate-2').
That passes the UI Zod (z.string) and API TypeBox (t.String), but the service inserts
it into a timestamptz column and Postgres throws 'invalid input syntax for type
timestamp with time zone' -> create 500s -> onSuccess/closeForm never fires -> form
stays visible -> 10s waitFor(hidden) times out -> false park.
Confirmed at the boundary against the live DB:
'dueDate-3'::timestamptz -> ERROR: invalid input syntax
'2024-06-15'::timestamptz -> 2024-06-15 00:00:00+00 (accepted)
Fix: validValue returns '2024-06-15' for date/datetime/timestamp types. Date-only so it
stays a substring of whatever timestamp representation the row cell renders back (the
shows assertion is toContainText). Boolean fields were already fine (checkbox path).
Regression test added. typecheck/lint/format clean, 3193/3206 suite green.
Follow-ups (filed): empty-optional-date '' also 500s a timestamptz insert (generated
form should coerce '' -> undefined for optional date/number); e2e seed resilience to
transient socket hang-ups / vitest worker timeouts under load.
…panel r1 finding)
- Exercise date, datetime AND timestamp (production branch handles all three).
- Replace the weak !isNaN(new Date()) check, which accepts normalized-impossible dates
(new Date('2024-02-31') rolls to 2024-03-02), with a strict UTC round-trip that rejects
them. Self-checks the checker rejects '2024-02-31' and accepts '2024-06-15'.
…lue (panel r2 finding) A date-typed field whose NAME matches the email heuristic (emailVerifiedAt, lastEmailSentAt) was getting user@example.com because the email name-check ran before the date-type branch — an email string 500s a timestamp-column insert, the same false-park class. Reordered so explicit type checks (email/number/date) run first, then name-based heuristics for string fields. Test covers emailVerifiedAt(timestamp) → real date, not an email.
…esFor (panel r3 finding) 3 reviewers converged: negativesFor still used f.type === 'email' || /email/i.test(name), so a date/number field named like an email (emailVerifiedAt) got a 'not-an-email' negative. That value reaches a timestamp/number column → 500 (not the expected 400/422) → false park — the same class validValue was just fixed for. Extracted a shared isEmailField(field) helper (explicit type wins over name; number/date types are never email) and used it in BOTH validValue and negativesFor so they can never disagree. Test asserts the negatives array: emailVerifiedAt(timestamp) gets NO not-an-email negative, a real email field DOES (positive control).
…ype-precedence, panel r4) isEmailField also guards number types (emailCount type=number → number sample + negative-number negative, never email). Added that case to the regression suite: numeric valid value (no '@'), no not-an-email negative, and the '-1' number negative present.
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
1 participant
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.
The wall
Live deep-chain build (Organization→Project→Task) parked the Task slice: fast gate green, but the e2e acceptance timed out with
task-formnever hiding. The build's own note guessed 'transient socket hang up' — but the boundary state (form stays visible) said the create was failing.Root cause
validValue(acceptance-spec.ts) had no case for date types, so adueDatefield got the generic"dueDate-2"sample. That passes UI Zod (z.string) and API TypeBox (t.String), but the service inserts it into atimestamptzcolumn → Postgres throws → 500 → create fails → form never closes → 10swaitFor(hidden)times out → false park.Confirmed at the live DB:
Fix
validValuereturns"2024-06-15"fordate/datetime/timestamptypes (date-only → substring-safe for the row-celltoContainTextshows assertion).validValueandnegativesForvia a sharedisEmailFieldhelper: a date- or number-typed field named like an email (emailVerifiedAt,emailCount) is not treated as an email — otherwise the positive sample /not-an-emailnegative feeds a non-date/number value into a date/number column and 500s (same false-park class).Tests
Date/datetime/timestamp valid samples with a strict UTC round-trip that rejects normalized-impossible dates (e.g.
2024-02-31); theemailVerifiedAtprecedence in both the valid sample and the negatives array; a genuine-email positive control; and a number-named-email (emailCount) case.Validation
Full suite: typecheck / lint / format clean, 3193 green.
Follow-ups (filed, not blocking)
''also 500s a timestamptz/number insert (generated form should coerce'' → undefined).