List Pages Restored After Identifier Validation Fault

Why This Matters

A recent internal migration widened our database identifiers to a larger numeric type. The database driver returns such values as strings to protect numeric precision, but several internal row-validation schemas still expected plain numbers and began rejecting every row they saw. The visible symptom: the categorisation rules page, the chart of accounts, and sibling list pages showed validation errors instead of data.

What Changed

• Row validation across all affected resources now accepts the driver’s string form and converts it safely, with invalid values still rejected. Fifty-six declaration sites across seven modules were corrected in a single audited pass, with the before and after counts verified to match.
• We deliberately did not change how the driver returns large numbers globally: monetary amounts depend on string precision end to end, and that protection stays exactly as it was.

How It Was Found

By us, using our own admin tooling during release verification, before any customer reported it. The fault had been present and silent since the identifier migration; the pages simply showed no data. A follow-up audit of every remaining identifier declaration against the migrated column list is now tracked.

---

Found by the system, not by a user.