Summary

  • INPROGRESS はタグなし OK に埋め込まれる途中経過であり、処理件数を示す場合もあれば、接続を切らせないための生存信号にすぎない場合もある。
  • コマンドの成否は同じコマンドタグを持つ最終 OK、NO、BAD が決める。検索結果や外部システムでの反映には、それぞれ別の証跡が必要だ。

進捗表示が長く止まると、利用者は障害を疑う。そこで表示が一目盛り動けば安心する。だが運用上の危険は、安心を判断根拠に変える瞬間に生まれる。

RFC 9585 の INPROGRESS は、安心のための情報を機械可読にしたものだ。たとえば 1,000 を目標に 999 を処理したという通知が来ても、あと一件で成功するという意味ではない。サーバーは追加作業を発見でき、目標値を変えられ、進捗を戻すこともある。最後に失敗応答が返る可能性も残る。

この拡張が必要になった背景は素朴だ。大きなメールボックスに対する検索やコピーは長引く。従来もサーバーは自由文で「処理中」と送れたが、クライアントが共通の規則で解釈できなかった。2024 年 5 月に Standards Track として公開された RFC 9585 は、INPROGRESS の capability と response code を定義した。

最初に確認すべきなのは capability である。対応サーバーは CAPABILITY 応答に INPROGRESS を含めなければならない。ただし、これは全コマンドに通知を出す約束ではない。最初の通知時刻より早く終わる処理なら、一度も途中経過を送らなくてよい。

通知を出す場合、推奨間隔は 10〜15 秒だ。目的は詳細な計測だけではなく、クライアントのタイムアウトを防ぐことでもよい。明細を持たない最小形式では、コマンドタグ、進捗、目標値のすべてが NIL と解釈される。これは「この接続上でサーバーが応答した」以上の情報をほとんど持たない。

明細付き形式は CMD-TAG、PROGRESS、GOAL の順に値を置く。進捗は処理済み項目数、目標は完了時に到達すると予想される総量だ。自然な項目数で数えられない仕事には、目標を 100、進捗を 0〜99 とする割合表示も認められる。

ここで重要なのは欠落が仕様に組み込まれていることだ。進捗が分からなければ進捗と目標は両方 NIL。総量だけ分からなければ目標が NIL。タグを取得できない場合や元のタグに ] が含まれる場合、タグも NIL になる。単一コマンドなら匿名の通知を手掛かりにできるが、複数コマンドが並行すれば帰属は確定できない。

数値の連続性も保証ではない。進捗は単調増加、目標は固定が望ましいものの、クライアントは逆の動きを扱う必要がある。仕様が勧める解釈は、以前の目標を達成した後に、サーバーがさらに長い作業を見つけたというものだ。これは実装を継続させるための意味付けであり、古い分母が総作業量だった証明ではない。

完了との境界は IMAP4rev2 の基本構文にある。* で始まるタグなし応答は、データまたはコマンドを終わらせない状態を伝える。完了応答は、クライアントが付けたタグを返し、成功なら OK、失敗なら NO、プロトコルエラーなら BAD となる。したがって INPROGRESS はタグなし OK にのみ現れ、タグ付き応答に入れてはならない。

表示上の OK という語だけを見ると誤る。* OK [INPROGRESS ...] は A001 の処理完了を示す A001 OK ではない。先頭のアスタリスクが途中状態を示し、対応するタグが完了を示す。この一文字の違いを消した UI やログ集約は、観測を命令へ変えてしまう。

さらに、完了と結果内容も別物だ。RFC の SEARCH 例では、処理数の通知が続いた後、タグなし SEARCH 応答が一致したメッセージ番号を返し、最後にタグ付き OK が来る。GOAL は一致件数ではなく、PROGRESS は検索結果でもない。最終 OK は成功を示すが、何が見つかったかは SEARCH 出力が示す。

仕様は、進捗評価以外の用途で数値を権威ある値として扱うことを禁じている。特に GOAL をフォルダー内メッセージ数の代わりに使ってはならない。COPY でも、処理済み数だけでは保存済み件数、索引完了、複製の収束、保管システムへの反映を証明できない。

無通知も停止の証拠ではない。最初の通知までは進捗ゼロ、目標不明と仮定するが、それはクライアント側の知識を表す初期値だ。短い処理は無通知で成功し得る。一方で、通知が規則的でも有用な仕事が進んでいるとは限らない。

受信値は防御的に扱う必要がある。悪意あるサーバーが算術例外や異常なメモリー消費を狙うかもしれない。目標ゼロ、負値、極端な数値、進捗が目標を超える通知などは捨てる。目標の変更や進捗後退は履歴として残し、滑らかな一本の線に補正してはならない。

運用では、割合より状態遷移を記録する。接続、認証済みセッション、capability、コマンドタグ、発行時刻、同時実行数を固定し、すべての通知を生のまま紐付ける。コマンド固有の出力は別に保存する。同じタグの完了応答を受けるまで実行中状態を維持し、その後必要なら外部状態を照合する。

タグ付き OK も権威の終点とは限らない。IMAP サーバーがプロトコル上の成功を報告したことは分かる。しかし、アーカイブ検索に索引されたか、法的保全が認識したか、別地域の複製が収束したか、顧客通知が送られたかは、各システムの受領証で確認すべき事実だ。

RFC 9585 は途中状態を有用にした。だからこそ、その途中状態を完了や結果に見せかけない実装が必要になる。

Sources