lib/elastic/transport/transport/errors.rb:37 creates subclasses of Elastic::Transport::Transport::ServerError for seemingly every 5xx, 4xx and 3xx HTTP status code ever specified, including nonsense ones that I assume elasticsearch would never return such as 418 IAmATeapot. Compare this to the much more sensible set of error classes defined by the python client library
Elasticsearch can return 5xx status codes for transient conditions where no resolution is required. In that case, client code can simply retry the same request.
The 4xx codes aren't server errors and shouldn't be classified as such - client code can handle these. For example, 409 Conflict is returned when attempting to update a document with a stale seqNo. This can be resolved in client code by refetching the document and merging desired changes.
A slightly more complex case occurs when conflict resolution appears possible but later becomes impossible. An example of this is when a stale update conflicts with a delete. The stale update first sees 409 Conflict, but refreshing the document causes a 404 NotFound. In that case client code handling 409 Conflict needs to report the 404 NotFound back to the user.
This sort of handling is complicated in the ruby client because
- every error subclasses ServerError so we can't separate transient issues (where retrying makes sense) from conflicts (where we need to do something client side to fix the request)
- the status code of the error is not retained, except in
#message. I'd rather avoid parsing the string in #message to extract the status code - that feels quite brittle.
There is a way to tell the client which status codes to retry on, but its unclear what to put in here since the API documentation implies 200 is the only possible response status.
lib/elastic/transport/transport/errors.rb:37creates subclasses ofElastic::Transport::Transport::ServerErrorfor seemingly every 5xx, 4xx and 3xx HTTP status code ever specified, including nonsense ones that I assume elasticsearch would never return such as418 IAmATeapot. Compare this to the much more sensible set of error classes defined by the python client libraryElasticsearch can return 5xx status codes for transient conditions where no resolution is required. In that case, client code can simply retry the same request.
The 4xx codes aren't server errors and shouldn't be classified as such - client code can handle these. For example,
409 Conflictis returned when attempting to update a document with a staleseqNo. This can be resolved in client code by refetching the document and merging desired changes.A slightly more complex case occurs when conflict resolution appears possible but later becomes impossible. An example of this is when a stale update conflicts with a delete. The stale update first sees
409 Conflict, but refreshing the document causes a404 NotFound. In that case client code handling409 Conflictneeds to report the404 NotFoundback to the user.This sort of handling is complicated in the ruby client because
#message. I'd rather avoid parsing the string in#messageto extract the status code - that feels quite brittle.There is a way to tell the client which status codes to retry on, but its unclear what to put in here since the API documentation implies 200 is the only possible response status.