CODEWITHSUNDEEP
google-cloud-pubsub
aMOSBURGER
aMOSBURGER

Reputation: 27

GCP pub/sub ordering pull subscription retry can cause out-of-order?

In this medium article, https://medium.com/google-cloud/google-cloud-pub-sub-ordered-delivery-1e4181f60bc8, it was stated:

The Cloud Pub/Sub service can’t guarantee the success or latency of the response it sends for a subscriber’s pull request. If a response fails and a subsequent pull request is fulfilled with a response containing subsequent messages for the same ordering key, it is possible those subsequent messages could arrive to the subscriber before the messages in the failed response. It also can’t guarantee that the subsequent pull request comes from the same subscriber.

I would like to check what it means with an example:

Subscriber pulls messages for ordering key "A" and receives batch B1 containing messages M1 and M2.
The subscriber encounters an error processing M2 and retries the pull request.
Before Pub/Sub sends a new response, it should include all unprocessed messages from the previous failed batch B1 (including M2) in the next response, along with any new messages published for the same ordering key since the failure.
Therefore, the next response (let's call it B2') would contain both M2 from the failed attempt and any new messages for ordering key "A" published after the error.

Is this example understanding correct? How would it be possible those subsequent messages could arrive to the subscriber before the messages in the failed response?

Would really appreciate any clarification!

Upvotes: 0

Views: 425

Answers (1)

Kamal Aboul-Hosn
Kamal Aboul-Hosn

Reputation: 17261

The key part is the sentence before what you quote: "The requirement that only one batch of messages can be outstanding at a time is necessary to maintain ordered delivery."

The remainder of the paragraph explains why only one batch of messages can be outstanding per ordering key. In your example, if M1 and M2 were already outstanding, then a subsequent pull request would not receive any more messages for key A. If the messages are acked, nacked, or expired (either due to the time expiring or due to the loss of tracking state for the set of outstanding messages), then a subsequent pull request could get messages for key A, starting with the first message that had not been acked.

Not that a subsequent response is not guaranteed to have all messages available for key A; it is just guaranteed to start with the first unacked message.

Upvotes: 0

Related Questions