著者は、セッション開始、ファイル転送、ビデオID取得、検証、ローカルレコード作成を含むシーケンシャルなプロセスでYouTubeアップロードシステムを開発しました。ローカルレコードが検証ステップの後にのみ書き込まれていたため、重大な欠陥が生じました。検証が失敗した場合、例外が発生してプロセスが停止し、ディスク上にアップロードされたビデオのレコードが残りませんでした。その結果、アップロードコマンドを再実行すると、既存のファイルチェックがバイパスされ、ビデオの重複アップロードにつながりました。システムのドキュメントでは、リトライによって重複が発生しないと誤解を招く記載がありましたが、これは外部からのプロセス全体の失敗後の再実行ではなく、内部の低レベルのリトライにのみ適用されました。これにより、同じビデオが2回アップロードされることになりました。リポジトリの別の部分でも同様のバグが発見され、古いプロセスを通じてアップロードされた5本のビデオも対応するローカルレコードがなく、重複の危険性がありました。著者は、既存のテストが合格したのは、例外発生後のディスク上のシステムの状態を考慮していなかったためだと指摘しています。修正は、ビデオIDを受け取った直後に、未検証とマークされていても、ローカルレコードを書き込むようにワークフローを変更することでした。このレコードにより、検証を再開するか、ビデオが既に処理されている場合はそれ以上のアップロードをブロックすることが可能になりました。既存の5本のビデオについては、手動でのレコードのバックフィルが必要でした。この根本的な問題は、リモートリソースを作成してから検証し、失敗した場合にリモートリソースは作成されたもののローカル状態が記録されないままになるウィンドウを作成する、あらゆる操作に一般化されます。このあいまいさがリトライロジックを無効にします。この解決策は、後続の検証に関係なく、IDを受け取った瞬間にそれを記録することに重点を置いています。また、リソースを作成するすべてのコードパスが、目に見えない不整合を防ぐために、同じブックキーピングシステムに貢献する必要があることも強調しています。