A long URL took the counter down

On 9 August 2026, twenty counter images failed to render. Not drew wrong, not drew slowly — the visitor got nothing at all where a counter should have been.

The cause was a page address longer than 255 characters.

The chain

The column that stores which page a visit landed on is varchar(255). The address arrived longer than that. The insert failed with SQLSTATE 22001, data too long for column, which in this code raised an exception.

And the statistics write happens before the image is drawn. So the exception did not just lose one row of statistics. It aborted the request, and the request was the one that produces the counter picture. A page with a long address broke its own counter, silently, for every visitor.

Long addresses are not exotic. A gallery with nested paths, a shop with a dozen tracking parameters appended by an ad platform, a search result page — any of these clears 255 characters without trying.

The fix, and the fix that was not chosen

The address is now cut to the column width before the insert. Twenty characters of a very long URL are lost from the page list; nothing else changes.

The alternative was to widen the column. It was rejected: there is no width that cannot be exceeded, and picking a bigger number only moves the same failure further away where it will be harder to recognise when it arrives. The failure mode has to stop being fatal, not become rarer.

Wrapping the insert in a try/catch would have fixed the visible symptom too, and it would have been worse: the counter would draw, the row would quietly vanish, and the page list would be missing exactly the pages with the most complicated addresses, forever, with nothing in any log.

Two things worth taking away

Foreign input belongs trimmed to the column width, not hoped to fit. Anything that arrives from outside — an address, a referrer, a user agent, a title — is as long as somebody else decided, and the database has an opinion about that which it expresses by refusing.

Know what else is downstream of your failure. This was a statistics bug in a statistics service, and the visible damage was a missing image. The write and the render shared a request; nothing in the code said they were coupled, and nothing warned that a failed insert would take the picture with it.

Twenty broken images in a day is small. It was found by reading logs for something else entirely, which is the usual way these are found, and the reason to keep reading them.