今日は、りすと亭4.02.0をリリースしました。
これは予定外の緊急リリースです。
そもそもは、利用者の方から、「古くなったメッセージを自動的に削除する」の機能を使用していると、イベントログに定期的に同じエラーが記録されるというレポートが発端でした。そこから、それに対する対策版の4.02.0をリリースするまで、わずか数時間というのは、(いつでも可能ではないとはいえ)、悪くないサポート時間ではないかと思いますが、それは本題ではありません。
問題は、どうして、こういう問題が起きたのかという理由と、どうして防止できなかったのかという理由です。
まず、問題が起きた理由から行きます。
「古くなったメッセージを自動的に削除する」の機能では、定期的に保存されているメッセージ数を調べて、それが指定数より多ければ、100メッセージ単位で多すぎる分を削除します。その際、あるメッセージが存在するかどうか調べてから、そのメッセージを削除する処理を繰り返します。問題は、存在していないメッセージについて、存在していると返してしまうケースがあったことです。これにより、存在していないメッセージを削除しに行って、FileNotFound例外が起きていたわけです。
より具体的に言うと、メッセージが存在するかどうかの判定は、拡張子.rawのファイルが存在するかどうかで調べるのが仕様です。しかし、それだけでなく、メッセージ番号を名前とするディレクトリがあれば、メッセージはある、というロジックが組まれていたのです。これは、りすと亭バージョン4の開発初期の仕様にのっとった動作です。開発初期には、シングルパートのメッセージはヘッダーと本文の2ファイルを保存し、マルチパートのメッセージは、メッセージ番号の名前を持つディレクトリを作成し、その中に各パートのヘッダーと本体を保存するような仕様になっていました。その後、様々な改良を加えることで、それとは異なる仕様に変化したにもかかわらず、このメソッドには古い仕様が生き続けていたわけです。
しかし、この動作は、通常問題を起こすことはないはずです。なぜなら、マルチパートのメッセージが保存される場合は、メッセージ番号の名前を持つディレクトリと、拡張子.rawのファイルの双方が同時に作成されるためです。つまり、どちらを判定しても、通常は上手く動作するはずなのです。
それにも関わらず、問題が起きるケースがあるのは、メッセージ番号の名前を持つディレクトリと、拡張子.rawのファイルが必ず同時に作成され、必ず同時に削除される、というシーケンスが常に守られるとは限らないためです。たとえば、手動でファイルを削除すれば、一発でこの整合性は破れます。破れてしまえば、システムは誤動作します。
このようなケースでも正常に動作するためには、プログラムの修正が必要であったわけです。
次に、このような問題を未然に防ぐことは出来なかったのか、という問題に移ります。このあたりのコードは、おそらく「テストファースト」の導入前に作成された部分であるため、自動テストが作成されていません。そのため、不適切な動作を自動テストで検出することはできなかったと言えます。現在の新規作成分は、基本的に自動テストとペアで作られるため、信頼性はかなりのレベルで維持されると言えます。今回の修正分も、まずテストを作成してから、テストをパスするようにソースコードを直しています。このテストは自動テストの一部を構成しているので、自動テストを繰り返す限り、まったく同じバグは再発しないと言えます。しかし、この問題に関しては、そのような自動テストの範囲外だったということです。
とはいえ、自動テストがあれば、この問題を確実に察知できたかというと、完全に察知できたとも言い切れないところがあります。というのは、あらゆる異常ケースに対応するテストを作成することは現実的には無理だからです。たとえば、どんな名前のディレクトリがある場合にも正常な判定を行う、というテストを作ったとしても、それは現実的な時間内に完了できないでしょう。名前を構成する文字の組み合わせの数が膨大すぎるのです。そのような意味で、テストは完璧ではありません。
テストで検出できない問題の存在を知るには、利用者の皆様のレポートが決め手になります。
皆様のお力があってこそ、りすと亭は存在しているのです。
レポートを下さる方々には感謝すると共に、ぜひ、何かおかしい動作を発見した場合には、レポートをお願いいたします。
