GRPC-Swift空闲流导致后续RPC返回Unavailable(14)如何提前检测

该错误是gRPC Swift端的连接状态更新延迟导致的：客户端侧公开的连接状态标记为ready时，底层HTTP/2连接已经被服务端/中间代理链路悄悄断开，客户端尚未完成状态同步，此时发起新的一元调用就会抛出NoSuchStream和Transport became inactive错误。你配置的keepalive未生效常见有三个原因：

• 服务端未开启grpc_keepalive_permit_without_calls参数，会直接忽略客户端无调用时发送的PING帧，甚至主动返回GOAWAY断开连接
• 中间七层负载均衡/网关的HTTP/2空闲超时小于你配置的15s，还没到keepalive触发时机连接就被链路切断
• iOS系统后台会暂停网络计时器，keepalive无法按时触发，回到前台时连接已经失效

• 方案1：调整keepalive和空闲超时配置
  将keepalive间隔调整为比链路最小空闲超时小20%以上，同时配置连接最大空闲超时，主动释放失活连接，示例配置如下：

let keepalive = ClientConnectionKeepalive(
    interval: .seconds(7), // 比常见的10s链路空闲超时小30%
    timeout: .seconds(5),
    permitWithoutCalls: true
)

self.connection = ClientConnection
    .usingPlatformAppropriateTLS(for: group)
    .withKeepalive(keepalive)
    .withConnectionIdleTimeout(.seconds(20)) // 超过20秒无交互主动断开重连
    .withCallStartBehavior(.waitsForConnectivity)
    .withErrorDelegate(self)
    .withConnectivityStateDelegate(self)
    .connect(host: host, port: port)

• 方案2：调用前增加连接预校验逻辑
  不要直接依赖公开的connectivityState状态，扩展ClientConnection增加PING校验方法，调用前先验证连接有效性：

extension ClientConnection {
    func ping(timeout: TimeAmount = .seconds(3)) -> EventLoopFuture<Void> {
        let promise = self.eventLoop.makePromise(of: Void.self)
        self.ping { result in
            switch result {
            case .success: promise.succeed(())
            case .failure(let error): promise.fail(error)
            }
        }
        // 超时直接判定连接失效
        let timeoutTask = self.eventLoop.scheduleTask(in: timeout) {
            promise.fail(NSError(domain: "GRPCConnect", code: -1, userInfo: [NSLocalizedDescriptionKey: "ping timeout"]))
        }
        promise.futureResult.whenComplete { _ in
            timeoutTask.cancel()
        }
        return promise.futureResult
    }
}

调用一元接口前先执行PING校验，失败则主动重建连接再发起请求。同时监听ErrorDelegate抛出的NoSuchStream、Transport became inactive错误，一旦捕获立即标记连接失效，主动关闭重建。

• 方案3：配置全局重试策略
  针对unavailable这类可重试的网络错误，配置内置重试策略，第一次调用失败后会自动在新建连接上重试，上层业务无感知：

let retryPolicy = RetryPolicy(
    maximumAttempts: 2,
    initialBackoff: .seconds(0.1),
    maximumBackoff: .seconds(1),
    backoffMultiplier: 2,
    retryableStatusCodes: [.unavailable, .aborted]
)

// 连接配置新增重试策略
self.connection = ClientConnection
    .usingPlatformAppropriateTLS(for: group)
    .withKeepalive(keepalive)
    .withRetryPolicy(retryPolicy)
    // 其余原有配置保持不变

• 方案4：利用现有流维持连接活性
  你有长期存在的ticksStream服务端流，可以监听流的数据回调，若连续10s没有收到流数据，主动发起一个轻量一元心跳请求（可让服务端新增空实现的ping接口），主动触发链路帧交互，避免连接被链路判定为空闲切断。

你当前的一元调用代码使用try!和wait()阻塞线程获取结果，建议改为异步实现适配重试逻辑：

let symbolsRequest: Pricing_SymbolsRequest = .with {
    $0.serverID = Int32(serverID)
    $0.symbols = requestSymbols
}

let call = service.symbolsData(symbolsRequest)
call.response.whenComplete { result in
    switch result {
    case .success(let response):
        callback(response)
    case .failure(let error):
        print("RPC failed: \(error)")
    }
}

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