Some runners set the context manager to return a 'raw' response to avoid the unnecessary client side overhead of deserialising the response body. For example, the Bulk runner selectively parses the response body to check whether the overall HTTP request contains any failed bulk items, but discards the rest of the body.
This works well for failures within the bulk request, but it doesn't solve for situations where the entire request fails. The recent Wikipedia track has been encountered difficult and vague errors during execution that look like this:
2023-11-21 01:01:28,169 -not-actor-/PID:15028 elastic_transport.transport INFO PUT https://10.10.12.39:9200/_bulk [status:413 duration:0.429s]
Running initial-documents-indexing [ 0% done]
[ERROR] Cannot race. Error in load generator [0]
Cannot run task [initial-documents-indexing]: Request returned an error. Error type: api, Description: <_io.BytesIO object at 0xffff99199cb0>
Even if detailed-results: true is set for the operation, we still get back the above vague error message that is including a string literal representation of the error body.
This commit ensures that we properly handle raw request exceptions, and those that return empty bodies. Testing with the Wikipedia track (as above) now returns:
Running initial-documents-indexing [ 0% done]
[ERROR] Cannot race. Error in load generator [0]
Cannot run task [initial-documents-indexing]: Request returned an error. Error type: api, Description: None, HTTP Status: 413
Some runners set the context manager to return a 'raw' response to avoid the unnecessary client side overhead of deserialising the response body. For example, the Bulk runner selectively parses the response body to check whether the overall HTTP request contains any failed bulk items, but discards the rest of the body.
This works well for failures within the bulk request, but it doesn't solve for situations where the entire request fails. The recent Wikipedia track has been encountered difficult and vague errors during execution that look like this:
Even if
detailed-results: trueis set for the operation, we still get back the above vague error message that is including a string literal representation of the error body.This commit ensures that we properly handle raw request exceptions, and those that return empty bodies. Testing with the Wikipedia track (as above) now returns: