Azure CLI Key Vault恢复软删除密钥后查询报错，是否存在内置重试策略

你碰到的偶发SecretNotFound报错、以及报错后又能正常输出校验结果的现象，是两个机制叠加导致的，和az keyvault secret show的内置重试逻辑没有关系：

• 第一是Azure Key Vault本身的最终一致性架构：Key Vault是多副本分布式存储服务，执行recover操作的请求被服务端接收后，不会在毫秒级同步到所有存储副本；紧随其后的show查询请求如果被负载均衡路由到还没同步到“密钥已恢复”状态的副本节点，就会直接抛出SecretNotFound错误；等几秒后跨副本同步完成，后续发送的查询请求自然就能拿到正确结果，看起来就像是CLI自己重试成功了。
• 第二是PowerShell对外部程序报错的默认处理逻辑：az cli是独立的可执行程序，不是PowerShell原生的cmdlet，它抛出的错误是直接写入stderr输出流的，不会自动转换成PowerShell的异常，所以哪怕报错文本直接打在控制台上，try/catch块也根本捕获不到。

你现在用的直接捕获recover命令返回值的方案，刚好从根源上绕开了一致性同步的时间差：

当你给recover命令加了--output json参数时，Azure服务端返回的JSON响应，是基于“处理这个恢复请求的节点已经确认密钥恢复完成”的前提生成的，响应本身就包含当前版本的密钥值。你直接拿这个返回值做比对，完全不需要等跨副本的同步完成，自然就不会遇到刚恢复就查询的同步延迟报错。

要彻底消除运行时的报错输出，可以按照下面的逻辑调整脚本：

• 执行恢复操作时，直接通过--only-show-errors过滤无意义的提示输出，同时把返回的JSON对象存到本地变量，第一时间完成值校验——这是最可靠的校验环节，不存在同步延迟问题
• 如果后续确实需要通过show命令做二次校验（比如确认密钥没有在恢复后被其他流程意外修改），必须给查询加显式的退避重试逻辑：
  • 设置最大重试次数（比如3-5次），每次重试间隔2秒
  • 把每次查询产生的stderr报错通过2>$null重定向丢弃，不会把中间的同步失败错误打到控制台
  • 只有当show命令执行后的退出码$LASTEXITCODE为0时，才解析返回的JSON做值比对，否则进入下一次重试
• 判断az cli命令的执行状态时，永远不要依赖PowerShell的异常捕获：外部程序的执行结果，要通过$LASTEXITCODE（值为0代表成功，非0代表失败）来判断，stderr的输出流不能作为错误判断的依据

• 不需要找所谓的“show命令内置重试策略”：az cli的Key Vault模块默认没有针对这类跨副本同步延迟问题的重试逻辑，所有看起来的“自动恢复成功”，本质都是跨副本同步最终完成后的自然结果
• 刚恢复密钥就连续无间隔调用show命令的行为，本身就会大幅提升同步报错的概率：连续多次报SecretNotFound、过一会又能查到的表现，是分布式系统最终一致性的正常表现，不是CLI的bug

内容的提问来源于stack exchange，提问作者awj