Pubsub triggers in Cloud run through EventArc doesn't support ordering now. Do you know whether it is a feature that would be available soon? Is there a workaround for it?
@@tianzicai9964 does Workflow triggers for PubSub EventArc events support ordering keys? If you have links to documentation on that it'd be great to see!
I have some question about ordering. Is pub/sub guarantee the message order (ordered by publish time) if there is only 1 subscriber with different ordering key between messages? I have an issue that the incoming message has a different ordering key, but I would like to consume them in order of publish time.
Hi, Pub/Sub basically doesn't guarantee ordering of any messages outside of a single ordering key. So messages inside the same key will always be delivered in order, but you can't rely on any other kind of ordering. The reason for this has to do with keeping more flexibility for more reliable delivery across different regions. I hope that answers your question! Small addendum: the ordering guarantee within an ordering key is actually the ordered received by the server rather than publish time. Those are generally the same thing, but in some edge cases, they might not be. If you do want total ordering, Dataflow is probably the right answer.
It is mentioned that subsequent messages are not delivered if the previous message is NACKed specifically in the "push" case...but what is the actual/intended behaviour in the "pull" case? I cannot find anything documented about this. From my observations and analysis of the .NET libraries, it would appear that the "pull" case brings down messages in batches, then iterates through them all irrespective of whether any are NACKed.
For NACK'ed messages, there should be no difference between the "push" and "pull" case. Your observation is valid, NACKed messages continue to be redelivered with their batch in the right order until they have been ACKed. Are you seeing a batch of messages like {A, B, C} where B has been NACKed, and the .NET client iterates through the batch?
Very useful deep dive explanation of Pubsub ordering keys.
Glad it was helpful!
Pubsub triggers in Cloud run through EventArc doesn't support ordering now. Do you know whether it is a feature that would be available soon? Is there a workaround for it?
@Vineehth, I wonder what makes you think so. EventArc does support ordering key. Would you appreciate more documentation or a quickstart around that?
@@tianzicai9964 does Workflow triggers for PubSub EventArc events support ordering keys? If you have links to documentation on that it'd be great to see!
I have some question about ordering. Is pub/sub guarantee the message order (ordered by publish time) if there is only 1 subscriber with different ordering key between messages? I have an issue that the incoming message has a different ordering key, but I would like to consume them in order of publish time.
Hi, Pub/Sub basically doesn't guarantee ordering of any messages outside of a single ordering key. So messages inside the same key will always be delivered in order, but you can't rely on any other kind of ordering. The reason for this has to do with keeping more flexibility for more reliable delivery across different regions. I hope that answers your question!
Small addendum: the ordering guarantee within an ordering key is actually the ordered received by the server rather than publish time. Those are generally the same thing, but in some edge cases, they might not be. If you do want total ordering, Dataflow is probably the right answer.
It is mentioned that subsequent messages are not delivered if the previous message is NACKed specifically in the "push" case...but what is the actual/intended behaviour in the "pull" case? I cannot find anything documented about this. From my observations and analysis of the .NET libraries, it would appear that the "pull" case brings down messages in batches, then iterates through them all irrespective of whether any are NACKed.
For NACK'ed messages, there should be no difference between the "push" and "pull" case. Your observation is valid, NACKed messages continue to be redelivered with their batch in the right order until they have been ACKed. Are you seeing a batch of messages like {A, B, C} where B has been NACKed, and the .NET client iterates through the batch?
Great video. Can we add a link to the previous video in the description that this one appears to follow on to?
Sorry about that. Here it is: th-cam.com/video/f8nQk62IkHM/w-d-xo.html