feat(customerpayment): reject zero + non-finite cpayAmount at the schema layer#172
Merged
CryptoJones merged 1 commit intoMay 19, 2026
Conversation
…ema layer `cpayAmount` was typed `z.coerce.number()` — which accepts: - **0**: a "\$0 payment" against a customer ledger has no business meaning. It's operator error every time, and the API was happily recording it. - **Infinity / -Infinity**: zod's `.number()` rejects NaN by default but lets the infinities through. A DOUBLE column will store them fine, then any consumer doing arithmetic (totals, aging buckets, CSV exports) gets contaminated. Negative values still pass — some operators model refunds as negative payments, and there's no separate refund flow on this API yet. Pin both that and the zero/infinity rejection in tests so the boundary is observable. Extracted the validator to a named `cpayAmountField` so the create and update bodies share one definition instead of drifting. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
CryptoJones
deleted the
feat/customerpayment-reject-zero-and-infinite-amount
branch
This was referenced May 19, 2026
CryptoJones
added a commit
that referenced
this pull request
May 19, 2026
) `injbAmount` was typed `z.coerce.number()`, which accepts every value `Number()` produces — including `Infinity` and `-Infinity`. zod's `.number()` rejects `NaN` by default but lets the infinities slip through. JSON has no literal for Infinity, but `z.coerce.number()` happily turns the string `"Infinity"` into the float, and the underlying Sequelize `DOUBLE` column will store it as `inf`. Any downstream consumer doing arithmetic on the column (invoice totals, aging buckets, CSV exports) then gets contaminated. Pin `.finite()` at the boundary so non-finite values get a clean 400 instead of corrupting the ledger. Zero and negative values still pass — both are real accounting cases on invoice lines (reference/courtesy $0 lines; credit/discount negative lines). This is intentionally looser than cpayAmount's non-zero refinement from the customer-payment side: a $0 payment is operator error, a $0 invoice line is normal. Extracted the validator to a named `injbAmountField` so create and update bodies share one definition (mirrors the `cpayAmountField` pattern from #172). Co-authored-by: Aaron K. Clark <akclark@thenetwerk.net> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
6 tasks
CryptoJones
added a commit
that referenced
this pull request
May 19, 2026
…chema layer (#194) Both `polQty` and `polPrice` were typed as bare `z.coerce.number()`, which accepts `Infinity` and `-Infinity` (zod's `.number()` rejects NaN by default but not the infinities). The coerce path also turns the string `"Infinity"` into the float, so even via JSON — which has no literal for Infinity — a client can land non-finite values in either column. Both columns are Sequelize `DOUBLE` and will happily store `inf`. An `inf` on a PO line silently corrupts every downstream calculation: PO totals, inventory valuation, GL reconciliation. Fix: extract `polQtyField` + `polPriceField` chained through `.finite()`, share between create and update bodies. Same pattern as the `cpayAmountField` (#172) and `injbAmountField` (#180) validators. Zero and negative values still pass — a $0 line is a real "freebie included with order" case, and a negative line is a valid inline credit/discount entry. Pinned in `tests/api/purchaseorderline.test.js` with 5 new tests covering: non-finite polQty rejection, non-finite polPrice rejection on POST and PATCH, and that zero + negative values still pass through (preserving the freebie / inline-discount use cases). Co-authored-by: Aaron K. Clark <akclark@thenetwerk.net> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2 tasks
CryptoJones
added a commit
that referenced
this pull request
May 19, 2026
…#206) `btHourlyRate` was typed `z.coerce.number().nonnegative()`. `.nonnegative()` correctly blocks negative rates (a -\$50/hr rate is operator error), but it does NOT block `Infinity` — `Infinity >= 0` is `true` so the refinement lets it through. The coerce path also turns the string `"Infinity"` into the float, so a client without an Infinity literal in JSON can still land `inf` in the underlying DOUBLE column. An `inf` in `btHourlyRate` silently contaminates every downstream total: invoice line totals, time-entry rate math, billing reports, anything that multiplies hours by this rate. The arithmetic doesn't fail — it just yields `inf` (or `NaN` from `0 * inf`) in the result. Fix: chain `.finite()` ahead of `.nonnegative()` in a shared `btHourlyRateField` validator. Mirrors `cpayAmountField` (#172), `injbAmountField` (#180), `polPriceField` (#194). Zero remains a valid rate (pro-bono engagements, internal-only billing entries). Pinned in `tests/api/billingtype.test.js` with 4 new tests: - POST non-finite → 400 - POST negative → 400 (existing nonnegative gate, pinned so a refactor can't accidentally relax it) - POST zero → not 400 (preserves pro-bono use case) - PATCH non-finite → 400 Co-authored-by: Aaron K. Clark <akclark@thenetwerk.net> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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.
Closes #171.
Summary
cpayAmountwas typedz.coerce.number(), which accepted three valuesthat have no business meaning:
0— a "$0 payment" recorded against a customer ledgerInfinityand-Infinity— zod rejects NaN by default but not theinfinities; the DOUBLE column happily stores them, then any consumer
doing arithmetic (totals, aging, CSV) gets contaminated
Negative values are intentionally still accepted — some operators
model refunds as negative payments and there's no separate refund flow.
Refactored into a shared
cpayAmountFieldso create and update bodiesshare one validator instead of drifting.
Test plan
npm run lintcleannpm test— 617 → 620 (+3 tests)cpayAmount: 0→ 400 (new)cpayAmount: -50→ not 400 (refund flow preserved, new)cpayAmount: 0→ 400 (new)Proudly Made in Nebraska. Go Big Red! 🌽 https://xkcd.com/2347/