There is a list of all possible RPC errors at this page: http://tezos.gitlab.io/api/errors.html According to my experiments, these errors are returned differently. I found at least two different ways to return an error in response to run_operation:

  1. Return 200 OK status code, put a list of errors into the operation_result object for the errors key.
  2. Return 500 status code with body containing a list of errors and no other data.

Example of 1:


Example of 2:


I have two questions:

  1. How does tezos-node decide which status code to use? Is it documented anywhere? My hypothesis was that it depends on the kind, but it's not the case because in my example all errors have "temporary" kind. My another hypothesis is that it depends on the number of reported errors: if there is only one error, 500 is returned, otherwise 200. But then why does 500 response have a list in its body?
  2. What's the point of returning 500 status code in these cases? It means "Internal server error" which I treat as "something is wrong on the server". But if I for example try to make an operation with a wrong counter, it doesn't mean that anything is wrong with the server. So I am confused.
  • There are indeed inconsistencies with the return codes, check out gitlab.com/metastatedev/tezos/-/issues/150. I think for calling scripted contracts, you'll get the first case you describe when an error is encountered in script execution, which is right. However, the second case error occurs if an error is thrown elsewhere in the protocol. I agree that 500 is not the right behavior. – Tomáš Zemanovič Jun 26 at 16:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.