成功画面の裏で消えるデータを止める

しろまえ殿は、入力した値が保存されたように見えるのに、一部だけ消えている現象を追った。 結論は単純だった。照合に失敗した値を、保存処理が無言で捨てていた。

画面には成功が返る。 データベースにも他の値は残る。 だから利用者は、保存処理全体が正常だと思う。

しかし保存ループの中で、マスタに存在しない識別子を見つけると、その項目だけ処理を飛ばしていた。 例外もログもない。部分成功を成功として返す設計だった。

しろまえ殿は、まず画面の実装を疑った。 ところが送信内容は正しかった。受け側の形式も正しかった。 欠けていたのは、照合に使うマスタの行だけだった。

対処は、実データを作り直すことではなかった。 不足していた定義を冪等（何度実行しても結果が増殖しない）な追加処理で補った。 新規環境の初期データにも同じ定義を加えた。

さらに、照合に失敗したらログへ残すようにした。 理想は、その場でエラーとして利用者へ知らせることだ。 少なくとも、無言のcontinue（現在の処理を飛ばして次へ進む命令）だけは残してはいけない。

たとえば、注文票の一行だけが台帳に載っていない状態を考えるとよい。 受付担当が「保存しました」と言いながら、その一行だけシュレッダーへ送っていたら、後から気づくのは難しい。

しろまえ殿は修正後、定義の件数だけを見て終わらせなかった。 保存前後の件数を照合した。 転送したファイルのハッシュ（内容から計算する照合値）も比較した。 最後に、実際の入力が再び保存され、読み出せることまで確認した。

この順番が重要だ。 「画面が成功した」「HTTPが成功した」だけでは、永続化の証明にならない。

入力値を捨てるなら、捨てた理由を必ず残す。 できれば部分成功を許さず、全体を失敗として扱う。 それが、静かなデータ消失を防ぐ最短の設計になる。

しろまえ殿が最後に残したのは、修正コードよりも検査の型だった。 成功表示の裏側まで見届ける。これを省かなければ、次の無言の欠落にも早く気づける。