fix: stop long float values becoming strings and corrupting weight totals (#377)

[sherrmann]

Fixes #377.

Split out of #378 (the chat tool-layer branch) so a user-facing crash fix does not wait behind a 37-commit feature. The two commits are cherry-picked unmodified; the third adds the changelog entry that would otherwise have landed under the wrong feature heading.

The crash was the second symptom, not the bug

The report was TypeError: e.toFixed is not a function on the home page, with a spool weight total of 2913718.838604448929592810524802001000955455597751000200 — 50-odd decimal digits. That number was never stored anywhere. It was built in the browser.

json-bigint's storeAsString option decides what to keep as a string by looking at the length of the raw literal (>15 characters), not at whether the value is an integer. So an ordinary gram value carrying float64 representation noise — 0.30000000000000004 is 19 characters — parsed as a string despite used_weight being a declared number.

The home page then computes sum + spoolStockWeight(s). One string operand turns + into concatenation, so from that spool onward every weight was appended as digits instead of added. That is the reporter's 55-digit number: a running concatenation, not a stored value. Any total downstream of the first noisy spool was silently wrong long before anything crashed. Sub-1000 g values then reached .toFixed() as strings and took the render tree down — which is the part that got noticed.

Fix

Three layers, because each is independently wrong:

1. Parse correctly. storeAsString: false, so long literals arrive as BigNumber instances. Unlike strings, those can be told apart from genuine string fields, so each is revived individually: only whole numbers beyond Number.MAX_SAFE_INTEGER become strings. The CockroachDB large-id behaviour from Fix JS integer-precision loss on large CockroachDB IDs that makes the UI 404 on vendor_id #69 is preserved exactly — that is what the option was there for, and it still works.
2. Formatters stop trusting their input. formatWeight, formatWeightCompact and formatLength now use the same Number() + Number.isFinite coercion that numberFormatter in the same file already used. A bad value renders as a dash instead of unmounting the page.
3. Stop generating the noise. used_weight is rounded on every write path. Six decimals, not one: enough to strip float64 representation noise, not so aggressive that it discards real sub-gram increments (a slicer can legitimately report ~0.03 g per layer). It rounds in SQL so the accumulator stays a single atomic UPDATE — rounding in Python would reintroduce the read-before-write that deadlocks MariaDB and forces CockroachDB serialization retries. The cast to Numeric is load-bearing: PostgreSQL and CockroachDB have no round(double precision, integer) overload.

The second commit removes the outer cast back to Float from that expression. It was a no-op on every supported backend — MySQL/MariaDB cannot CAST to FLOAT so SQLAlchemy dropped it with a warning, and on SQLite/PostgreSQL the UPDATE ... SET assignment already coerces to the column type. Compiling every dialect with and without it produces byte-identical SQL, so the warning was its only observable effect.

Tests

• client/src/utils/bigintJson.test.ts — long non-integer literals stay numbers; oversized integers still become strings (Fix JS integer-precision loss on large CockroachDB IDs that makes the UI 404 on vendor_id #69 unregressed).
• client/src/pages/home/analytics.test.ts — the concatenation path: a noisy weight in a list of spools must sum, not concatenate.
• client/src/utils/parsing.test.ts — formatters survive string/NaN/undefined input.
• tests_integration/tests/spool/test_use.py — repeated small use calls leave used_weight free of float64 noise, on every supported database.

Verified on this branch: 925 backend tests and 90 client tests in the touched files, all green.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Fixes a frontend crash and silent corruption of weight totals caused by long float literals being parsed as strings by json-bigint, and reduces future risk by rounding used_weight on write paths and making client formatters defensive.

Changes:

• Client: replace json-bigint “store long literals as strings” behavior with BigNumber + reviver so only oversized integers become strings (preserves CockroachDB ID behavior).
• Client: harden formatWeight, formatWeightCompact, and formatLength against string/NaN/undefined inputs (avoid .toFixed() crashes).
• Backend + tests: round used_weight consistently (including atomic SQL accumulator) and add regression coverage across client and integration tests; add changelog entry.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
tests_integration/tests/spool/test_use.py	Adds integration regression test ensuring repeated small use increments don’t accumulate float noise.
spoolman/database/spool.py	Adds SQL-side rounding helper and applies rounding across used_weight write paths.
client/src/utils/parsing.tsx	Makes weight/length formatters defensively coerce non-numeric inputs.
client/src/utils/parsing.test.ts	Adds tests for formatter coercion and noisy-float rounding behavior.
client/src/utils/bigintJson.ts	Reworks bigint JSON parsing to revive BigNumbers and only stringify oversized integers.
client/src/utils/bigintJson.test.ts	Adds tests for long noisy floats, MAX_SAFE_INTEGER boundary, and oversized integers.
client/src/pages/home/analytics.test.ts	Adds end-to-end test covering JSON parsing + home weight summation (prevents string concatenation).
CHANGELOG.md	Documents the crash + silent-total-corruption fix and the multi-layer remediation.

Suppressed comments (1)

spoolman/database/spool.py:411

• SpoolUpdateParameters also allows used_weight: null on PATCH. With the new rounding branch, round(v, ...) will throw if v is None, producing a 500. Add a null guard so the API rejects this invalid update instead of crashing.

        elif k == "used_weight":
            # A caller can also set used_weight directly (#377): round it the same way.
            spool.used_weight = round(v, WEIGHT_ROUND_DECIMALS)

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[sherrmann]

Note on the automated review finding about spool.py null weights

The Copilot reviewer on #378 flagged that update() crashes when a caller sends an explicit "used_weight": null or "remaining_weight": null — both are float | None in SpoolParameters, and model_dump(exclude_unset=True) keeps an explicitly-passed null, so the value reaches round(None, 6) / the subtraction.

The finding is real, but I checked whether this branch introduces it, and it does not. Probing the actual endpoint on both trees:

field	master (696483c)	this branch
used_weight: null	TypeError: unsupported operand type(s) for -: 'NoneType' and 'float'	TypeError: type NoneType doesn't define __round__ method
remaining_weight: null	TypeError: unsupported operand type(s) for -: 'float' and 'NoneType'	TypeError: unsupported operand type(s) for -: 'float' and 'NoneType'

Both fields already 500 on master. This branch changes only the message of the used_weight failure — the null now meets round() a few lines earlier than it previously met the arithmetic — not whether it fails or what status the caller sees.

So it is a genuine pre-existing bug (a 500 where a clean 422 belongs) and worth its own issue, but it is not a regression from this fix and is out of scope for a crash fix that is being kept deliberately small.

🤖 Generated with Claude Code