データクロールでは、取得できた文書が検索エンジンのマッピングに合わず、一括登録の最後のバッチだけが失敗することがあります。Fessで、文書単位の失敗理由をWARNへ出す変更と、最終コミットの失敗をクロールログ・障害URLへ記録する変更がマージされました。
文書単位の拒否理由
従来は一括登録で拒否された文書の情報がDEBUG中心で、通常運用のログでは対象や理由が分かりにくい状態でした。修正後は、拒否された各文書についてURL、ID、ステータス、エラー種別、理由をWARNに記録します。
理由の長さは500文字までに制限します。マッピングエラーが付加するフィールド値のプレビューはログから除きます。ただし、#3616と#3624だけでは、後続の例外メッセージや数値変換の理由にフィールド値が残る経路があります。#3643はこれらも除去する提案ですが、今回の取得時点では未マージです。ログと障害URLに文書内容が絶対に含まれないとは扱わず、共有前に内容を確認してください。設定項目を追加して有効化する方式ではなく、修正された処理のログ出力が変わります。WARNが出力されるログレベルで運用することが必要です。
送信文書数と応答件数が一致せずURLを対応付けられない場合、URLはnullとなります。文書IDなど他の情報で調べます。文書単位の問題としてWARNにしているため、この出力だけでERROR通知が発生するとは限りません。
最終コミット失敗も記録する
データストアの処理終了時には、まだバッファーに残った文書をコミットします。この処理で例外が発生すると、修正前はクロールスレッドの未捕捉例外となり、クロールログや障害URLへ記録されない場合がありました。
修正後は例外を捕捉し、ERRORログと障害URLに記録します。最終コミットが失敗した場合は、その後の古い文書削除を実行しません。登録に失敗した文書が置き換えるはずだった既存文書を、削除処理で消さないためです。
調査と再実行
取得件数と登録件数が合わない場合は、WARNの文書ID・エラー種別、最終コミットのERROR、該当データ設定の障害URLを確認します。たとえばmapper_parsing_exceptionなら、送信した値の型と検索インデックスのマッピングを比較します。型や変換処理を直してからクロールを再実行します。
文書単位のWARN処理自体が、各拒否文書をすべて障害URLとして登録するわけではありません。最終コミットの失敗記録はデータクロール設定の単位です。また、今回の変更は失敗の可視化であり、自動再試行やマッピングの修復を追加するものではありません。