Is order guaranteed between watchers on the same watch RPC?

[mladedav]

First of all I just want to make sure about one assumption since "watch" seems to be used sometimes for a single watcher on a given watch RPC identified with a watch_id and somtimes for the whole RPC. Watch API states that events are atomic. I assume this guarantee applies only to a single watcher on the given stream, right? I.e. if there are two watchers, one for key x and another for y and both are changed in a single revision, the watch will produce two different responses with different watch_ids and different events.

When we create a new watcher, we are allowed to provide its watch_id and the documentation states (emphasis mine):

If watch_id is provided and non-zero, it will be assigned to this watcher. Since creating a watcher in etcd is not a synchronous operation, this can be used ensure that ordering is correct when creating multiple watchers on the same stream. Creating a watcher with an ID already in use on the stream will cause an error to be returned.

I have not found any mention about inter-watcher ordering guarantees anywhere else.

What are those guarantees?

Is it guaranteed that revisions are ordered? I.e. we cannot get update on revision 7 for one watcher and only then update on revision 6 for another?

Is there a guarantee that updates for different watchers always come in e.g. ascending order with the watch_id? E.g. if we receive update on watcher with ID 7, we can be sure that there will be no update for watcher with ID 6 on the same or lower revision?

Is there any guarantee about progress_notify for watchers on the same stream, e.g. if we receive an update for one watch we can expect an update for all others (which have opted in for these notifications)?

[serathius]

https://etcd.io/docs/v3.6/learning/api_guarantees/#watch-apis

[mladedav]

Thanks for the reply, but I don't see an answer on that page. This again speaks only about a single watch inside a bi-directional watch RPC. My question is what are the guarantees between different watches on the same stream.

For example, I have created a watch stream and started watching for prefix /foo. This got watch_id=0. Next on the same gRPC stream I started a watch for prefix /f. This got watch_id=1. When I created an entity with key /foo/1, both watches got an update, so two responses arrived, each referring to the same revision and the same key. The two protobuf packets were almost identical except for the watch_id. Interestingly, watch_id=1 came first.

The docs I have quoted earlier mentioned ordering of watchers. So I assume there are some guarantees regarding the watchers and their ordering, otherwise there would be no point in caring about the order, right?

[serathius]

My question is what are the guarantees between different watches on the same stream.

There are none

[mladedav]

Oh ok. That answers all my questions I guess, but what's the point of giving the users the option to choose the watch_id then? The docs say we can guarantee an order but if the ordering does not provide any further guarantees then I don't see the point?