Don't treat client error same way as server error.

[serathius]

What would you like to be added?

Robustness tests assume all errors are network errors. This means we don't known if and when request has been processed.

However there are some client side errors that we were correct handled by server and returned to client . Those errors are send as grpc code and later translated by client to golang error interface.

For example "required revision is a future revision"

Why is this needed?

Make visualization more readable.

[serathius]

/cc @henrybear327 @nwnt @joshjms

[serathius]

/cc @ahrtr

[ahrtr]

I recall there are several discussions about the etcd's errors in the past several years, also @lavacat and @mitake had spent some effort/investigation on this area as well. I don't think we have a well defined (at least not well documented) errors list.

We have server side (including etcdserver errors and grpc errors, confusing...) and client side errors, and some conversion between them, but users might not care too much about whether it's a server side error or client side error. Again, there isn't a clear summary or document on this.

From users (including robustness test) perspective, there should be a well defined list of errors, users should be able to depend on the returned error to decide whether they should retry or not, although not always possible.

A success response guarantees that the etcd server has processed the request. However, an error response does not necessarily mean the request failed — the server might have completed the request, but the response could have been lost (e.g. due to network issues). Therefore, while not always possible, users can sometimes use error details to tell whether the request itself failed or if the response was simply lost.

BTW, there are two types of users, we should document errors for both cases,

• Most use etcd via the client SDK.
• Some run etcd embedded inside their apps.

[serathius]

This issue is related to robustness tests, not generic etcd errors. We want to just fix the linearization cost.

[serathius]

As for the issue you are rising, I recommend looking the GRPC code of the error. For example ErrGRPCFutureRev uses OutOfRange grpc code. I think client should look at that.