IssueTracker

Please describe the feature or enhancement you are requesting.

On occasion, user will receive HTTP 200 responses from the Vision API but the error is encoded into the payload:

"error": {
"code": 4,
"message": "image-annotator::RPC deadline exceeded.: Backend timeout!"
}

It seems this is due to the batching nature of the API (some of the responses could be good). User has a retry strategy for HTTP 5xx and 429 error codes and they would also like to implement retries for these types of requests but I'd like to understand:

***Are there a list of these codes documented? The only error documentation they could find was focused on errors generated with a failed HTTP status [1]. They'd like to retry on only the errors where it make sense. For instance, an " image-annotator::Malformed request." most likely shouldn't be retried.
[1]https://cloud.google.com/vision/reference/rest/v1/Code

So, the feature request is error encoded into the payload should not return HTTP 200 or some indication about error. And the doc needs to updated about the retry strategy explaining which errors need to retried.  

What business case or problem would this feature help you to solve?

1. There is no list of error code which needs to retried. For example for error code :4, Should it be retried or not? Users like to retry on only the errors where it make sense. For instance, according tot them an "image-annotator::Malformed request." most likely shouldn't be retried.
2. Another example error from the build server:
code=13,message=image-annotator::error(12): Image processing error! Console shows nothing but 200s for every attempt it made.
3. Users are concerned about incur a cost for backend timeout like this.

What workarounds or alternatives have you considered? In what way were
these unsuitable for your needs?
There is no current work around.  


What version of the product are you using? On what operating system?

1.They are using the Java API Client (v1-rev17-1.22.0) with the TEXT_DETECTION feature. The Java API does not treat these as errors (it doesn't throw an exception) and it's up to the application to detect and handle them.
2. They are running these requests on google compute engine VMs.