長い間待っていて一度もタイムアウトに遭遇しなかった場合、それはこの製品の冪等リトライロジックに問題がないことを意味しますか？
そのように推論することはできない。長期間タイムアウトに遭遇しなかったことは、「あなたのネットワーク環境とこの製品のサーバーの間で、今のところ運良く比較的安定した接続を保っている」ことしか証明せず、逆にこの製品の冪等リトライロジックが十分厳密に設計されていることを証明するものではない。なぜなら冪等リトライロジックはもともと平常時には完全に見えず、特定の状況（ネットワーク不安定）でのみ本当にテストされる環節だからだ。本シリーズで前述したサーバークラッシュのリスクも同様の性質を持つ。
この状況を実際に観察する機会が長期間ない場合、より現実的な方法はステップ5で述べた間接的な判断方法に戻ることである——技術文書を直接確認する、またはサポートに尋ねる。「自分はまだ問題に遭遇していない」ことをこの環節が既に検証済みであることの証拠として扱うのではない。この2つは全く別のことである。
操作が実際に二重実行されたことに気づいた場合、プラットフォームに連絡すること以外に何ができますか？
最初にすべき価値があるのは、この事件の全ての証拠を完全に保存することである——この操作をトリガーした正確な時刻、アプリのインターフェースが表示したエラーやタイムアウトメッセージのスクリーンショット、ブロックチェーンエクスプローラーで確認した重複する2つの取引のハッシュ値を含む。これらの具体的な証拠は、プラットフォーム側がこの事故を確認し対処する効率を大幅に高め、後にさらなる追及が必要になった場合の重要な根拠ともなる。
さらに、この種の事故が実際に発生した場合、本シリーズで前述した原則を振り返って適用する価値もある——このプラットフォームがこの事故にどう対処する姿勢を示すか（問題を正直に認める意欲があるか、どれだけ速く賠償や救済を完了するか）を観察することは、事故自体が起きたかどうかよりも、このチームの全体的な品質をよく反映する。プラットフォーム側がこの種の具体的で証拠のある事故に対してもなお回避や引き延ばしを選ぶなら、それは技術的な見落とし自体よりも警戒に値するシグナルである。
この5つのステップは、タイムアウトに遭遇して初めて実行できるように聞こえますが、実際一般の人はどれくらいの頻度でこの状況に遭遇しますか？
この頻度は製品やネットワーク環境によって異なり、固定の数字はないが、DeFAI製品を長期的かつ頻繁に使用していれば、遅かれ早かれネットワーク状況が理想的でない瞬間に少なくとも数回は遭遇すると合理的に予想できる（自分自身のネットワーク信号が不安定である、ブロックチェーンネットワーク自体が混雑している時間帯にたまたま当たるなど）。これらの状況はいずれもタイムアウトをトリガーする可能性がある。意図的にこの状況を待ったり作り出したりする必要はなく、本当に遭遇した際に、反射的にすぐに再操作するのではなく、もう少しの忍耐を持ってこの検証を行うことを覚えておくだけでよい。
評価した結果、製品の使用頻度が高くなく、短期間でこの状況に遭遇する可能性が低いと考える場合、それについて不安を感じる必要もない。ステップ5の間接的な判断方法に直接進み、技術文書を確認することでまず予備的な信頼の基盤を築き、将来本当にタイムアウトの状況に遭遇した際に、このチェックリストでさらなる実際の検証を行うことができる。
この製品の自動再試行メカニズムが、元の取引状態を全く確認せずに直接再送信していることに気づいた場合、それはこの製品が必ず安全でないことを意味しますか？
これは明確で真剣に受け止める価値のあるネガティブなシグナルだが、この製品が必ず資金の重複実行事故を起こしたことがある、または起こすことを意味しない——これはタイムアウトが実際にどれくらいの頻度で発生するか、そしてタイムアウトが発生するたびに元の取引が確かに失敗している確率に依存する。この製品の技術アーキテクチャが取引確認速度を非常に速くしており、タイムアウトが発生する確率が極めて低い場合、冪等性保護の設計が十分厳密でなくても、実際に問題がトリガーされる確率は比較的限られている可能性がある。
しかし確率が限られていることは完全に無視してよいことを意味せず、これは依然として構造的な設計上の欠陥であり、この発見をポジション計画における保守的な要因として扱う価値がある。実際に応用する際は、1回の操作あたりの金額をやや保守的に設定し、万が一本当に重複実行がトリガーされた場合の実際の損失規模を減らすことを検討できる。これはプラットフォーム側に技術アーキテクチャの即座の修正を要求できない状況で、あなた自身が取れる具体的な保護措置である。
本シリーズでは以前冪等リトライロジックについて触れた——ネットワークタイムアウトによってエージェントがトリガーする自動再試行は、適切な保護がなければ、実際には既に成功している操作を二重に実行させてしまう可能性がある。この記事では、あなたが使っているDeFAIエージェントがこの状況に対して適切な保護を備えているかを判断するのに役立つ、実用的な検証方法を提供する。
この検証は取り消し遅延の実測よりも意図的にトリガーするのが難しい。なぜならネットワークタイムアウトを能動的に発生させることはできないからだ。より現実的な方法は忍耐強く待つことである——ほとんどのユーザーは長期的に使用していれば、遅かれ早かれ少なくとも一度は「操作を送信した後、インターフェースがなかなか反応を示さない」という状況に遭遇する。これがまさに冪等リトライロジックが有効に機能しているかを観察できる機会である。
ある操作が固まって反応がないことに気づいたら、まず辛抱強く待ち、ブロックチェーンエクスプローラーを通じて、この取引が実際には既にオンチェーンで確定しているかを直接確認する。アプリのインターフェースでもう一度確認を押すのを急がないようにする。このステップの目的は、元の取引の本当の状態をまず確認し、その後の比較の基準とすることである。
使用している製品自体に自動再試行メカニズムがある場合、タイムアウトを検知した後の具体的な挙動を観察する——それはまず元の取引のオンチェーン状態を確認するか、それとも無条件に新しい取引を直接送信するか？インターフェースが処理プロセスの何らかの詳細を表示している場合（「以前の取引の状態を確認中」といったメッセージなど）、これは具体的なポジティブなシグナルである。
プロセス全体が終わったら、実際の資産変動記録を確認し、この操作が最終的に一度しか実行されず、再試行によって二度実行されていないことを確認する。資産変動の金額がちょうど予想の2倍であることに気づいたら、冪等リトライロジックが機能しなかった実際の事例に遭遇したことを意味し、直ちにプラットフォーム側に連絡する必要がある。
この状況を実際に観察する機会が今のところない場合、この製品の技術文書を直接確認するか、サポートに「冪等性」（idempotency）や「再試行保護」（retry protection）といった言葉への明確な言及があるか尋ねることができる。この用語の登場は、通常チームがこの問題に確かに対処したことの具体的な証拠である。
冪等リトライロジックは、平常時には全く現れず、ネットワークが不安定になったその瞬間にのみあなたの資金が安全かどうかを決定する環節である。この検証方法にはプログラミングの知識は全く不要で、本当にタイムアウトに遭遇した際に、自分でもう一度確認を押すのを急ぐのではなく、まず元の取引の本当の状態を検証するもう少しの忍耐があればよい。