A product table sorted with (a, b) => a.price - b.price shows a few rows in obviously wrong positions on the full dataset, though a short test list sorts fine. How do you diagnose and fix it?

## Reading the symptom Two details in the report point straight at the cause. First, the misplacement is *partial* — most rows are ordered correctly, a few are not. A comparator that is simply backwards or compares the wrong field would be wrong everywhere. Second, it reproduces on the full dataset but not on a short test list. Sorting is deterministic for a given comparator and input, so "works small, fails large" means the comparator's answers are not self-consistent and the engine's internal strategy is exposing that inconsistency differently at different sizes. ## The mechanism `a.price - b.price` assumes both operands are numbers. Real data disagrees: a price may be `null` for an unpriced item, `undefined` if the field was never set, or a formatted string such as `"1,299"` that fails numeric conversion. Any of these makes the subtraction `NaN`. The sorting operation converts the comparator's return value with `ToNumber` and, when the result is `NaN`, uses `+0` instead. `+0` means "these two are equivalent". So a row with a broken price is declared equal to *every* row it is compared with. That is not just a misplaced row — it destroys transitivity. If `bad` equals `10` and `bad` equals `99`, an ordering algorithm may legitimately conclude that `10` and `99` are interchangeable in some region of the array. The specification's rule is explicit: if the comparator is not a consistent comparison function, the sort order is implementation-defined. The corruption is therefore free to spread beyond the offending rows, which matches "a few rows in obviously wrong positions". ## Diagnosing it Start with the data, not the algorithm: ```js const suspects = rows.filter( r => typeof r.price !== 'number' || Number.isNaN(r.price) ); console.table(suspects); ``` If you need to catch it in place, wrap the comparator: ```js const audited = (cmp) => (a, b) => { const r = cmp(a, b); if (typeof r !== 'number' || Number.isNaN(r)) { console.warn('bad comparison', a, b, r); return 0; } return r; }; rows.sort(audited((a, b) => a.price - b.price)); ``` For a stronger guarantee, assert the contract over the data rather than eyeballing output: for sampled pairs check antisymmetry (`sign(cmp(a, b)) === -sign(cmp(b, a))`) and for sampled triples check transitivity. A property-based test that generates records including nulls and strings catches this class of bug permanently, and it is the test the original short unit test failed to be. ## Fixing it Three parts, in order of importance. **1. Normalise the key.** Convert once, before sorting, so the comparator only ever sees numbers: ```js const priceOf = (r) => { const n = typeof r.price === 'number' ? r.price : Number(String(r.price).replace(/,/g, '')); return Number.isFinite(n) ? n : Infinity; // missing prices sort last }; ``` **2. Define the missing-value policy explicitly.** "Unpriced items go last" is a product decision, not an accident of `NaN` propagation. Encoding it as `Infinity` (last) or `-Infinity` (first) makes it visible and testable. Never let missing data mean "equal to everything". **3. Make the order total.** Append a unique tiebreak so two genuinely equal prices always resolve the same way: ```js const byPrice = (a, b) => priceOf(a) - priceOf(b) || a.id - b.id; ``` With that, the output is a pure function of the data — identical between runs, between engines, and between server and client. That matters most when the list is paginated: an unstable or inconsistent order can make a row appear on two pages, or on none. ## Cost note `priceOf` now does string work. Called inside the comparator it runs on the order of n log n times. For a large table, decorate first — map each row to `{ key: priceOf(row), row }`, sort on `key`, then map back — so the parsing cost is paid once per element rather than once per comparison. ## The lesson to state out loud JavaScript reports none of this. There is no exception, no warning, no `NaN` leaking into the output — the comparator silently degrades into "everything is equal" for the affected pairs. Any comparator that touches user- or API-supplied data has to guarantee it returns a real number for every possible pair, and the tests have to exercise inputs longer and dirtier than the happy path.