Andrey Martyanov

Could you please describe what are you going to achieve from a client perspective?

As far as I know there is no indication in etcd RPC responses that changes somehow belong to the specific transaction, but you always can track revision changes.

I think the easiest thing we could do is to annotate distinct KVs from watch responses with an unique auto incrementing IDs to distinguish watch events, this way all the...

I've already mentioned revision in one of my previous replies and you're right the revision itself is not enough to distinguish the last event from watch response, that is why...

Agree with you about `is_last`. The issue needs more thought.

@honglei many thanks for the report. Concurrency API is great. Unfortunately, the current state of aetcd3 is far from complete, it's more of a POC than a reliable solution. And...

@stalkerg vanilla gRPC backend is already implemented. Regarding concurrency API there is no ETA.

@pengyao thanks! I'm currently in the process of refactoring the library, I'll check this later.

Hey @pengyao, many thanks for your MR. I'll take a look after #19.

@garvenlee `aetcd` is mostly a thin wrapper over native `gRPC` transport used by `etcd`. In this particular case what `refresh_lease` does is just iterate over replies https://github.com/martyanov/aetcd/blob/v1.0.0a4/aetcd/client.py#L1032C6-L1038C25, you can see...