"Unsupported number" is what PDFKit said when it crashed.

Not "out of memory." Not "document too large." Just: this number I received is not supported.

The number was Infinity. A layout calculation had tried to size something that had no finite size — a block of content too large for any reasonable coordinate system — and JavaScript quietly handed back Infinity instead of an error. Then Infinity traveled through several more calculations, untouched, until PDFKit tried to write it to a PDF file, looked at it, and gave up.

The fix involved multiple layers. Chunked rendering so no single pass dealt with too much content. Guards that caught Infinity and NaN before they reached the PDF writer. A hard cap on how many items to display. Caching via Supabase Storage so the expensive render happened once, not every time.

But what I keep thinking about is the gap between "unsupported number" and the actual problem. The actual problem was: a researcher profile had hundreds of papers. The error message described a symptom five hops downstream. Every layer in between — the layout system, the coordinate math, JavaScript's silent Infinity propagation — was just passing the problem along, not naming it.

Debugging usually isn't solving the error. It's finding the real question hiding behind the error.