あと34本で、記事が消え始める作りだった

サイト全体を見直していて、あと34本で記事が消え始める作りになっていることに気づきました。

エラーは出ません。ビルドも通ります。ただ、書いた記事が一覧にもサイトマップにも出なくなります。

1行だけの問題だった#

CMSへの問い合わせに、こう書いてありました。

posts(first: 100) {

「最初の100本を取ってくる」という意味です。書いた当時は記事が10本もなく、100は十分に大きい数でした。

いま66本あります。残り34本。

101本目に何が起きるか#

ここが厄介なところです。何も起きません。

気づく手段が、「あれ、あの記事どこへ行った」と思うことだけです。しかも消えるのは一番古い記事か新しい記事かも、並び順次第で変わります。

上げるか、外すか#

いちばん簡単なのは、100を500にすることです。1文字の修正で済みます。

ただ、それだと同じ壊れ方が先に延びるだけです。500本書いたときに、同じように何も知らせずに消え始めます。そのときの自分は、いまより確実に忘れています。

そこで、区切りそのものを外しました。

posts(first: 100, after: 前回の続きの位置) {
  pageInfo { hasNextPage endCursor }
  ...
}

100本ずつ取って、「まだ続きがある」と言われているあいだは取りに行き続けます。記事が何本になっても、全部取れます。

同じ数字が、もう1か所にあった#

直したあと、他にも同じ書き方が無いか探しました。サイトマップを作る処理にも、同じ100が入っていました。

こちらのほうが影響は大きい。一覧に出ないだけなら内部リンクからは辿れますが、サイトマップから漏れると検索エンジンに存在を知らせる手段が減ります。

両方とも同じ形に直しました。

気づけたのは、数えたから#

この問題は、使っていても出てきません。見つかったのは、サイト全体を機械的に確かめていたときでした。

やったのは単純で、数を数えることです。記事が何本あるか、サイトマップに何件載っているか、一覧に何枚並んでいるか。

どれも見た目には出ていません。数えないかぎり、全部「問題なし」に見えます。

今回の学び#

まず、「当分平気な数字」は、平気なあいだに忘れられるということ。書いた時点では正しい判断でしたが、正しさが長く続くほど、その存在を思い出すきっかけが無くなります。

次に、上限を上げるのは、同じ壊れ方を先送りにするだけだということ。500にしても、500本目に同じことが起きます。そのときの自分が覚えている見込みは、いまより低い。

そして、使っていて気づけない問題は、数えるしかないこと。表示は正常、ビルドも成功、エラーも無し。この状態で問題を見つける手段は、動かすことではなく数えることでした。