你點選「使用Google繼續」，選擇你的帳戶，接下來應該看到的就是ToRun。很多人看到的卻是一個要求他們去確認電子郵件的頁面——那正是三十秒前Google剛剛代表他們驗證過的同一個地址。
我們是透過統計發現這個問題的。自從要求已確認地址才能登入的規則生效以來，透過Google建立的帳戶中，超過四分之一從未登入過：沒有任何工作階段，一次都沒有。他們建立了帳戶，卻撞上了一堵牆。
為什麼會這樣
我們使用的框架只在一條分支上自動確認地址：即註冊過程中使用者輸入驗證碼的流程。這條分支在我們這裡是關閉的，因為社群註冊沒有地方可以輸入驗證碼。於是每一次Google或Apple登入完成，都會建立一個未確認的帳戶，向服務商剛剛為之擔保的信箱傳送確認連結，並在沒有讓任何人登入的情況下跳轉到確認頁面。
沒有任何環節報錯，也沒有記錄任何錯誤日誌。這個頁面甚至看起來是可以合理展示給使用者的東西。
針對這種情況本應有一項保護，幾週前就已加入，卻從未被觸發過——因為它存在於登入頁面，而兩個Google按鈕走的完全是另一條路徑。
一出生就已確認
透過Google或Apple建立的帳戶現在會以「已確認」狀態開始，只要註冊的地址確實是服務商實際聲明的地址。如果服務商明確表示未驗證該地址，這份信任就不會被給予，舊流程照常執行。如果確認因任何原因失敗，舊流程同樣會執行，連結也會被傳送。
框架原本會觸發的確認信現在以靜默方式處理，而不是傳送出去，因此不會有人收到一封要求確認某個早已確認事項的信件。
地址本身在完成頁面上現在是唯讀的，並附有一行以29種語言呈現的說明，解釋服務商已驗證該地址。而在手機上，從註冊跳轉到驗證畫面會重設導航堆疊，因此返回手勢會落在登入畫面，而不是一個使用者名稱和地址仍可編輯的半填寫表單上。
無需修復任何人
被困在舊牆後面的帳戶不需要遷移。他們下一次點選「使用Google繼續」就會完成確認——這一點自從之前的一次修復以來就已成立，也是整條復原路徑。
本應捕捉到這一問題的檢查——讀取登入路徑並確認每條路徑行為的那項檢查——在此問題存在的四週裡始終顯示綠色，因為它監視的每一個掛勾都存在於這條流程從未觸及的頁面上。現在它在這條流程真正觸及的頁面上新增了十二項檢查。