身份验证 API 超时：恢复流程而不默认视为通过

问题与你需要做的决定

一位卖家注册后，你的服务打开了托管身份会话，而服务商响应缓慢、无法连接或毫无回音。你的代码仍需决定用户看到什么、应用允许什么。这个决定不是简单的通过或失败，而是应记录哪种状态、下一步由谁处理。GridZen 的服务商故障指南说得很清楚：服务商不可用是运营故障，而不是低风险信号。当前的 Twilio 适配器在服务商不可用时通过 API 返回 503，而且 alpha 版本不会悄悄把这种故障转换为允许。审核队列或经授权的备用方案必须由调用方工作流自行实现。请把三种结果分开：不匹配是服务商返回的明确判断；证据不足表示你的策略缺少某个必需信号；技术故障表示检查本身没能完成。HTTP 状态要与决策结果分开记录，503 绝不应被记为拒绝或允许。

已检验示例实际实现了什么

可下载示例是一个无外部依赖的合成示例，不是真实服务商适配器。其身份部分使用 SQLite 持久化会话。调用 create 会保存一个状态为 pending 的会话，截止时间等于 now 加 timeout；使用默认值（now 为 0，timeout 为 60）时，截止时间为 60。返回的 hosted_link 指向一个无效的示例域名，link_executable 为 false，next 为 send_real_provider_link_only_after_authorization。event 方法只接受合成回调：mode 必须是 synthetic_fixture，source 必须是 fixture_callback，否则抛出 PRODUCTION_SIGNATURE_VERIFIER_NOT_IMPLEMENTED。事件标识必须以 fixture- 开头。这里没有任何真实签名验证。在截止时间当刻或之后到达的事件，会把会话标记为 expired，而不是应用事件中的状态。无法识别的状态会被标记为 unknown，而不是去猜测。recover 方法只在本地把截止时间已过、状态为 pending、review 或 unknown 的会话设为过期：它返回 provider_polled 为 false，从不联系服务商。任何 permission_granted 值都只是本地示例记录，live_permission_changed 始终为 false。

假设场景与预期输出

假设：在时间 0 创建合成会话 fixture-session，超时为 60 秒。对服务商的调用超时，也没有回调到达。在时间 61，你的后台任务调用 recover。经过测试的输出为：mode 为 synthetic_fixture，session 为 fixture-session，status 为 expired，deadline 为 60，permission_granted 为 false，grant_count 为 0，live_permission_changed 为 false，policy_version 为 1，allow_action 为 true，next 为 review_or_authorized_provider_refresh，provider_polled 为 false。没有任何内容被批准，下一步指向人工审核或经授权的服务商刷新，而不是假定成功的自动重试。对比同样经过测试的正常路径：在截止时间内收到 Approved 合成事件且 policy 为 true 时，得到 status 为 approved、permission_granted 为 true、grant_count 为 1。重放同一事件会返回完全相同的记录，grant_count 仍为 1。随后的 Declined 更正得到 status 为 declined、permission_granted 为 false、grant_count 为 1。过期之后到达的迟到回调无法让会话复活，因为对普通事件而言 expired 是终止状态。

在你自己的设计中处理失败

以下是建议的应用设计，而不是 GridZen 已实现的行为。把请求超时视为技术故障：保存 HTTP 结果，让会话保持 pending，并依赖已持久化的截止时间，而不是内存中的计时器。只有在上游操作和你的工作流都允许时才进行有上限的重试，之后转交审核。绝不要把超时、格式错误的响应、缺失凭据和服务商拒绝映射到同一个状态。当 recover 返回 expired 时，向用户显示中性的提示，并通过正常流程提供新的会话，或转交给负责人。示例中的错误码可用作契约检查：针对未知会话的事件会抛出 BINDING_MISMATCH，读取未知会话会抛出 SESSION_NOT_FOUND。即使状态为 approved，handoff 输出也会设置 verified 为 false，next_action 为 read_current_evidence_and_policy_before_explicit_decision，因为 Approved 并不是无条件的许可。

需要明确说明的限制

该示例只证明本地状态转换。它不验证真实签名，不轮询任何服务商，其中的授予也不是真实的业务许可。对于托管的 Didit 入驻，会话创建、签名回调和权威结果获取已有证据，但一个新用户完整走完托管流程仍未经测试，端到端的真实客户操作也仍未验证。真实路由是否可用需要另行确认。匿名的三场景 HTTP 试用与这个可下载示例是不同的产物，不要把两者混为一谈。

验收清单

在申请沙盒集成之前，请确认：pending 会话已持久化，其截止时间在重启后依然有效；超时被记录为技术故障，与决策结果分开；在截止时间当刻或之后调用 recover，返回 status 为 expired、permission_granted 为 false、provider_polled 为 false；迟到或重复的回调不会改变 grant_count；Declined 更正会撤销本地授予；未知状态变为 unknown，而不是 approved；已处理 BINDING_MISMATCH 和 SESSION_NOT_FOUND 错误码；审核或经授权的备用方案有明确的负责人；没有任何日志把 503 记为允许或拒绝。如果这些检查在本地全部通过，下一步是可选的已保存沙盒请求，而不是真实许可。

运行已检查的模拟示例

下载并解压 https://gridzen.ai/downloads/verification-delivery.zip，进入 verification_delivery，用 Python 3.10+ 运行。此本地示例不联网；独立身份实验请使用新的数据库。

python3 delivery.py identity --db /tmp/gridzen-article-fixture.sqlite

来源与范围

https://gridzen.ai/guides/provider-failures/ https://gridzen.ai/guides/current-capabilities/ 依据已检查的来源快照与本地模拟；建议的业务规则属于设计建议，不代表已证明的生产行为。内容使用 AI 辅助写作，并经过独立审稿。