長いアドレスがカウンターを倒した

2026 年 8 月 9 日、二十枚のカウンター画像が描かれませんでした。誤って描かれたのでも、遅く描かれたのでもありません — 訪問者はカウンターがあるはずの場所で何も受け取れませんでした。

原因は 255 文字を超えるページのアドレスでした。

連鎖

訪問がどのページに着いたかを記録する列は varchar(255) です。アドレスはそれより長く届きました。挿入は SQLSTATE 22001、列に対してデータが長すぎる、で失敗し、このコードではそれが例外になります。

そして統計の書き込みは画像を描く前に起きます。つまり例外は統計の一行を失っただけではありません。リクエストそのものを中断させ、そのリクエストこそがカウンターの絵を作るものでした。長いアドレスを持つページが、自分のカウンターを、静かに、すべての訪問者に対して壊していたのです。

長いアドレスは珍しくもありません。入れ子のパスを持つギャラリー、広告基盤が十数個の追跡パラメータを付ける店舗、検索結果ページ — どれも 255 文字を苦もなく超えます。

とった直し方と、とらなかった直し方

アドレスは挿入前に列の幅へ切り詰められるようになりました。非常に長いアドレスはページ一覧で二十文字ほど欠けます。それ以外は何も変わりません。

代案は列を広げることでした。見送りました。超えられない幅というものは存在せず、より大きな数字を選ぶことは同じ故障をより遠くへ、来たときにより気づきにくい場所へ押しやるだけです。故障のしかたが致命的でなくなる必要があるのであって、まれになる必要があるのではありません。

挿入を try/catch で包んでも見えている症状は治ります。そしてそれはもっと悪い。カウンターは描かれ、行は静かに消え、ページ一覧からはいちばん複雑なアドレスのページだけが永久に抜け落ち、どこにも記録は残りません。

持ち帰るべき二つ

外から来た入力は列の幅に切り詰めるもので、収まることを願うものではありません。外から届くもの — アドレス、参照元、ブラウザの識別、タイトル — は、他人が決めた長さです。データベースはそれについて意見を持っており、拒否という形でそれを表明します。

自分の故障のしかたの下流に何がぶら下がっているかを知ること。これは統計サービスにおける統計の不具合で、目に見えた被害は画像の欠落でした。書き込みと描画は一つのリクエストを共有していました。コードのどこにも両者が結び付いているとは書かれておらず、挿入の失敗が画像を道連れにするとも警告されていませんでした。

一日に二十枚の壊れた画像は少ない数です。見つかったのはまったく別の用事でログを読んでいたときで、これはこの種のものが見つかる普通のやり方であり、ログを読み続ける理由でもあります。