Pulumi创建GCP MemoryStore Redis首次报错误码13二次执行成功求助

这个首次创建失败、重试后成功的场景绝大多数是私有服务访问配置的异步同步延迟导致的，以下是具体排查和修复方案：

• 检查私有服务访问的前置依赖
  你使用connectMode: "PRIVATE_SERVICE_ACCESS"模式创建Redis实例，要求VPC提前完成私有服务访问的预留IP范围分配、连接建立配置。如果你的Pulumi工程中同时包含私有服务访问相关资源的创建逻辑，首次执行时GCP侧的网络配置还未完成全局同步，就会触发内部错误。第二次执行时网络配置已经生效，实例就可以正常创建。
  修复方案：给Redis实例资源显式添加dependsOn配置，关联你创建私有服务访问连接的资源，示例如下：

  // 假设你的私有服务访问连接资源定义为privateServceAccessConn
  const redisCache = new gcp.redis.Instance("my-redis-cache", {
            name: "my-metadata-cache",
            tier: "BASIC",
            memorySizeGb: 1,
            authorizedNetwork: pulumi.interpolate`projects/someprojectid/global/networks/default`,
            connectMode: "PRIVATE_SERVICE_ACCESS",
            redisVersion: "REDIS_6_X",
            displayName: "My Metadata Cache",
            project: someprojectid,
        }, {
            ...defaultResourceOptions,
            // 显式声明依赖私有服务访问配置
            dependsOn: [privateServceAccessConn]
        });
  

• 查看GCP后台操作日志
  错误码13属于GCP侧未透出具体原因的内部错误，你可以登录GCP控制台，进入「内存存储(Memorystore)」的操作日志页，筛选对应时间段的实例创建失败记录，查看后端详细错误信息，确认是否是配额临时校验失败、区域资源不足等其他问题。
• 调整Pulumi资源创建时序
  Pulumi默认会并行创建无依赖声明的资源，如果你的工程中还同时创建VPC、防火墙规则等关联资源，没有显式声明依赖的话也会出现时序问题。你可以拆分首次执行的步骤，先执行网络相关资源的pulumi up，确认网络配置生效后再执行Redis资源的创建。
• 配置自定义超时重试
  你可以在Redis实例的资源选项中添加自定义超时和重试配置，降低同步延迟导致的失败概率，示例如下：

  const redisCache = new gcp.redis.Instance("my-redis-cache", {
    // 原有配置不变
  }, {
    ...defaultResourceOptions,
    customTimeouts: {
      create: "10m"
    },
    retryOnConflict: true
  })
  

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