A Low‑Level Bug Caused by Decimal Precision Mistake: Lessons on Code Review, Testing, and Process

A few days ago I posted a rant titled "A Foolish X's Low‑Level Bug". Many readers were curious about the details, so I decided to revisit the incident.

Background

The issue originated from a common interest‑calculation formula: Interest = Principal * DailyRate DailyRate = AnnualRate / 360 Initially the daily rate was stored with 7 decimal places. Later the business demanded 11 decimal places, and I updated the stored values via a simple SQL script.

During the update I mistakenly entered 0.00069444444 instead of the correct 0.00006944444 , inflating the daily rate tenfold and consequently the calculated interest tenfold.

Why Was It Not Detected?

The change bypassed code review because I had both commit and review permissions and approved my own change. The testing team only verified that the SQL syntax was correct; they did not validate the numeric correctness of the data. Moreover, the production verification sampled only the correctly‑updated rows, missing the erroneous ones.

How Was It Exposed?

The error surfaced when I happened to notice an unusually large interest amount during an unrelated data check. Tracing back revealed the faulty SQL, which had already produced erroneous data for three days.

Reflection

The root cause was a simple typo, but the incident highlighted gaps in review, testing, and monitoring processes. It reinforced the importance of strict change‑management procedures, especially for business‑critical parameters, and reminded developers to avoid directly manipulating production data whenever possible.