chick
274e25961a
中继答 504 并说"可能已经执行了，重试前请先确认"——这句话诚实的前提是它保持为真。 批次是串行处理的，所以满邮箱里第八个信封可以在它被签名之后 8 个上游超时才轮到； 那时手机早已被告知失败、用户可能已经重试。再执行它，就把一次诚实的"未知"变成了 一条重复发出的短信。 现在 agent 在动任何东西之前先比对自己的截止时间（策略里的 requestTtlSeconds）， 超龄一律以 expired 拒绝并落审计。判定放在新鲜度检查之后、策略判定之前：它比签名 更便宜，而且一个过期请求无论路径是否在白名单里都不该执行。 为了让这条规则**可达**，策略新增一条断言：TTL 不得大于时钟偏移窗口。否则新鲜度 检查会先触发，这条规则永远不会被执行——而"永不触发的规则"是出事时才会被发现坏了 的那种东西。 单个上游调用的超时也移进了策略（agentUpstreamTimeoutSeconds）。"中继期限必须长于 一次上游调用"这个比较，与二进制里的常量是比不了的；现在两侧从同一个文件读，策略 加载时就能拒绝一组自相矛盾的数值。原来那个 20s 常量保留为默认值的来源，不再硬编码。 测试两项：一个请求在期限内被转发、一个超龄请求被拒且**没有被转发**（计数按路径， 否则首次转发前的 /api/auth/status 探测会让断言以错误的理由通过）；另一项断言策略 本身满足上述两个关系。变异验证：关掉判定，第一项失败。 Go 全包、Node 119 项、Swift 101 项通过。