调用GCP Pub/Sub REST API确认消息后消息仍留存的问题咨询

问题结论 #

GCP Pub/Sub的subscriptions:pull接口自带排除已成功确认消息的机制，正常操作下已完成确认的消息不会被再次返回。你遇到的重复拉取到相同messageId、不同ackId消息的情况，和机制本身无关，属于操作或配置异常导致的问题。

常见原因 #

• 确认请求未执行成功
  调用acknowledge接口时如果出现报错，确认操作不会生效，消息超过ACK截止时间后就会被重新投递。你需要先检查Postman调用确认接口时返回的HTTP状态码：如果返回4xx类错误（如ackId过期、订阅路径填写错误、账号无确认权限），都会导致确认失效。
  注意：ackId是单次拉取有效的标识，每次拉取同一条消息都会生成不同的ackId，且默认有效期仅为10秒，使用过期的ackId发起确认会直接失败
• 订阅配置问题
  如果你的订阅设置的ACK截止时间过短，你还未完成确认操作，ackId就已经过期，消息会被自动判定为未处理，触发重新投递。
• 至少一次投递语义的正常表现
  Pub/Sub默认采用至少一次投递的设计，极端低概率下哪怕你已经成功确认了消息，也可能出现重复投递的情况，但该场景不会高频出现。

排查建议 #

1. 调用确认接口后，校验返回结果：成功的确认请求会返回200状态码和空响应体{}，只要返回非200状态码，都代表确认没有生效
2. 核对拉取和确认操作使用的订阅路径完全一致，不要出现拉取用订阅A、确认填订阅B的错误
3. 调整订阅的ACK截止时间到合理范围，避免ackId提前过期
4. 你当前拉取请求中returnImmediately参数传入的是字符串"false"，该参数实际为布尔类型，建议修改为false避免解析异常

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