A quantity can escape the range check without being a number
When a quote-preparation screen accepts malformed input, first establish the validation rule and the actual conversion. A failed check may be a bounded defect in an otherwise suitable application, rather than evidence that the whole platform must be replaced.
The following fictional example concerns a staff tool preparing a request for replacement covers. The owner permits whole-unit quantities from 1 to 20 in this particular request route. Larger or otherwise unusual requirements use a separate review process. This is a business rule for the example, not a general limit on products or orders.
Inspect the value before the comparisons
Fixture Q-81 contains the text two in the quantity field. The application's JavaScript routine converts the value using Number. That conversion produces NaN, the language's non-number numeric value.
The routine rejects a value only if it is less than 1 or greater than 20. For NaN, neither comparison is true. The rejection branch is therefore skipped and the draft is incorrectly treated as having passed its quantity check.
The flaw is not that the word should be guessed as 2. The agreed input route requires a valid whole-unit quantity, and the original string needs a correction request. Converting an uncertain value into a plausible amount would change the user's evidence.
The ECMAScript specification defines explicit finite-number and integer tests. These questions are separate from whether an already valid number lies between two bounds.
Write the acceptance rule in the right order
The corrected route first establishes that a value was actually supplied in the accepted input format. It then checks that the converted result is finite, is an integer and is between 1 and 20 inclusive. The application preserves the original supplied string for a correction message; it does not rewrite the draft with a guessed quantity.
Format needs its own decision. In this fictional interface, the owner accepts decimal digits representing a whole count and does not accept exponent notation, decimal fractions or a word. The format check covers the entire trimmed input, so a numeric prefix followed by unrelated text is insufficient.
The receiving system applies the corresponding requirement independently. A valid browser state cannot establish that every request came through that browser or retained its checks.
Compare the corrected results
| Supplied value | Why it matters | Accepted outcome |
|---|---|---|
two |
Original malformed fixture | Request correction; no quantity inferred |
2 |
Ordinary whole count | Quantity 2 retained |
0 |
Finite integer below the business minimum | Rejected for this route |
1 and 20 |
Both inclusive boundaries | Accepted |
21 |
Above the approved range | Directed to the defined correction/review path |
1.5 |
Finite value but not a whole-unit count | Rejected |
Infinity |
Non-finite value | Rejected |
| Empty input | No quantity supplied | Required-value correction |
2e1 |
Numeric notation outside this interface's accepted format | Rejected rather than silently reinterpreted |
The tool's operator corrects Q-81 to the deliberately supplied value 2. The revised draft then contains quantity 2, the same equipment reference and the unchanged customer note. The correction history identifies that the operator changed the input; it does not present 2 as the value originally received.
A neighbouring request with a valid quantity of 6 remains unchanged. Neither fixture creates an accepted commercial order merely by passing this field check. The organisation's later assessment and quotation decisions continue to apply.
Compare repair with replacement using demonstrated capabilities
The existing application already stores request references, supports correction messages and allows the receiving validation to be changed. The defect is a missing validity boundary before a range test. The maintainer can reproduce it and demonstrate the corrected outcomes in the supported private arrangement.
The owner selects the focused repair, including the receiving check, original-value handling and contrasting cases. A replacement would need to reproduce those existing capabilities without adding a demonstrated benefit for this particular defect.
That decision is bounded. It does not establish the state of every calculation or every other input in the application. Similar validation patterns may warrant a separately defined review, especially where their consequences differ.
Keep the evidence with the maintained rule
The handover states the accepted format, finite/integer requirement, range and route for an unusual request. It retains the malformed original and boundary controls so that a future change cannot be judged using only the successful value 2.
If the business later decides to accept fractional quantities or a larger range, that is a rule change with a receiving-system and wording review. Removing the finite-number check would not be a necessary part of such a change.
Bring the original value, expected rule and observed result to application repair. The project planning page helps define what the first investigation should establish before a rebuild becomes the assumed answer.