你点击「使用Google继续」，选择你的账户，接下来应该看到的就是ToRun。很多人看到的却是一个要求他们去确认邮箱的页面——那正是三十秒前Google刚刚代表他们验证过的同一个地址。
我们是通过统计发现这个问题的。自从要求已确认地址才能登录的规则生效以来，通过Google创建的账户中，超过四分之一从未登录过：没有任何会话，一次都没有。他们创建了账户，却撞上了一堵墙。
为什么会这样
我们使用的框架只在一条分支上自动确认地址：即注册过程中用户输入验证码的流程。这条分支在我们这里是关闭的，因为社交注册没有地方可以输入验证码。于是每一次Google或Apple登录完成，都会创建一个未确认的账户，向服务商刚刚为之担保的邮箱发送确认链接，并在没有让任何人登录的情况下跳转到确认页面。
没有任何环节报错，也没有记录任何错误日志。这个页面甚至看起来是可以合理展示给用户的东西。
针对这种情况本应有一项防护，几周前就已加入，却从未被触发过——因为它存在于登录页面，而两个Google按钮走的完全是另一条路径。
一出生就已确认
通过Google或Apple创建的账户现在会以「已确认」状态开始，只要注册的地址确实是服务商实际声明的地址。如果服务商明确表示未验证该地址，这份信任就不会被给予，旧流程照常运行。如果确认因任何原因失败，旧流程同样会运行，链接也会被发送。
框架原本会触发的确认邮件现在以静默方式处理，而不是发送出去，因此不会有人收到一封要求确认某个早已确认事项的邮件。
地址本身在完成页面上现在是只读的，并附有一行以29种语言呈现的说明，解释服务商已验证该地址。而在手机上，从注册跳转到验证界面会重置导航堆栈，因此返回手势会落在登录界面，而不是一个用户名和地址仍可编辑的半填写表单上。
无需修复任何人
被困在旧墙后面的账户不需要迁移。他们下一次点击「使用Google继续」就会完成确认——这一点自从之前的一次修复以来就已成立，也是整条恢复路径。
本应捕捉到这一问题的检查——读取登录路径并确认每条路径行为的那项检查——在此问题存在的四周里始终显示绿色，因为它监视的每一个钩子都存在于这条流程从未触及的页面上。现在它在这条流程真正触及的页面上新增了十二项检查。