feat(invoicejob): reject non-finite injbAmount at the schema layer#180
Merged
Merged
Conversation
`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: 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 #179.
Summary
injbAmountwas typedz.coerce.number(), which accepts theinfinities. JSON has no Infinity literal but coerce-from-string
"Infinity"lands as the float, and the DOUBLE column storesinf.This PR adds
.finite()to a sharedinjbAmountFieldvalidator(mirrors the
cpayAmountFieldpattern from #172). Zero and negativevalues remain valid — both are real accounting cases on invoice lines.
Test plan
npm run lintcleannpm test— 628 → 632 (+4 invoice-line amount tests)'Infinity'→ 400 (new)'-Infinity'→ 400 (new)0→ not 400 (preserves the reference-line use case, new)-50→ not 400 (preserves credit/discount, new)Proudly Made in Nebraska. Go Big Red! 🌽 https://xkcd.com/2347/