GCP PubSub Java订阅进入RUNNING状态后出现认证错误的原因及解决方案

现象成因 #

PubSub客户端采用异步分层的启动设计：
本地侧的订阅配置加载、协程调度资源初始化、本地连接池预创建完成后，客户端就会立即将订阅状态标记为RUNNING，避免同步等待网络IO拖慢启动速度。而和PubSub服务端的认证握手、权限校验逻辑被放到后台异步执行，等后台请求返回凭据无效、权限不足的错误时，才会将状态更新为FAILED，二者的时间差就会导致先返回RUNNING后报错的假象。

规避方案 #

• 调整启动成功的判断规则：不要仅以RUNNING状态作为启动成功的标志，额外监听首次服务端心跳响应成功、首次消息拉取成功的事件，两个条件同时满足后再向业务层返回启动成功
• 增加启动后校验窗口期：订阅进入RUNNING状态后，用协程延迟等待2~3秒（可根据实际网络环境调整），窗口期内持续监听状态变更，如果出现FAILED状态直接抛出异常，窗口期结束无异常再返回成功
• 封装自定义状态层：在官方提供的6种状态基础上，新增PREPARING、READY两个自定义状态，只有完成服务端校验后才将状态更新为READY，业务层仅感知READY状态即可，屏蔽底层状态的时间差问题

启动前预先校验凭据的可行性 #

可以实现，常用两种校验方案搭配使用：

• 本地预校验：如果使用的是本地密钥类凭据，启动订阅前先解析校验凭据的格式合法性、有效期，提前拦截格式错误、过期的无效凭据，该方法无法校验服务端侧的凭据撤销、权限不足等问题
• 服务端预校验：启动订阅前先主动调用PubSub的轻量管理接口，比如getSubscription()查询目标订阅的配置，该接口会同步完成凭据合法性、操作权限的全量校验，接口调用成功再执行订阅启动逻辑，调用失败直接抛出凭据相关错误

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