google-cloud-rust icon indicating copy to clipboard operation
google-cloud-rust copied to clipboard

Determine if special handling is needed for ordered delivery in subscriber

Open dbolduc opened this issue 1 month ago • 0 comments

Pub/Sub supports ordered delivery for subscriptions.

In callback-based APIs, the client libraries guarantee that a callback for a message with a given ordering key completes before any subsequent callbacks on the same ordering key start. So says the Pub/Sub folks.

Note that applications can acknowledge messages outside of these callbacks. i.e. serving subsequent messages for a given ordering key is not blocked on receiving acknowledgement of previous messages.

In a streaming API, each call to next() of the stream is essentially a callback starting and finishing. So I do not think we need to do any special handling to make the same guarantee.

This issue is to confirm that my understanding is correct. We can close it if it is.

If an application acks messages out of order for a given ordering key, that is their prerogative. If the Ack IDs make it into the same ack batch, they will be acked. If not, they won't be, and there will be redelivery of some of the messages.

We do not want to prevent this at the cost of letting applications intake more messages into an (ordered) queue before acking.

dbolduc avatar Dec 02 '25 21:12 dbolduc