A Bug in Production
How one unlucky alphanumeric identifier was interpreted as scientific notation and brought an e-commerce site down.
Today I want to tell you about a bug that felt unexpectedly philosophical.
At first glance, what data type would you assign to these values?
5818d70dd0bf050001777772
57d053eb6bc24300012b1cc0
582646933170e00001768588
The obvious answer is that they are alphanumeric strings. That is true for the first two, but the last one creates an unusual edge case.
Look at it more closely:
582646933170e00001768588
The randomly generated identifier is made almost entirely of digits and contains a single letter: e.
In mathematics and many programming languages, e can introduce scientific notation. PHP, for example, understands this expression:
$value = 1e6; // 1000000
Now imagine a generic conversion function attempting to infer the type of our three identifiers. The result can be surprising:
5818d70dd0bf050001777772 // string
57d053eb6bc24300012b1cc0 // string
582646933170e00001768588 // INF
The final value happened to match the grammar of an enormous number in scientific notation. PHP represented the overflow as INF rather than preserving the identifier as text.
That unexpected interpretation caused a chain of failures and eventually took the e-commerce site offline. The lesson was painfully ordinary: identifiers are identifiers, not numbers, and automated coercion is dangerous at system boundaries. It was also a convincing reminder to write tests for values that look almost—but not quite—like the common cases.